Qu'est-ce que le processus «secd»?

Je me demande quel secdprocessus fait sous OSX Yosemite. Je suis presque sûr d'avoir vu ce processus s'exécuter dans les versions antérieures de MacOS, mais je ne me souviens pas qu'il ait englouti toute la mémoire disponible si hardiment ...

J'ai trois ordinateurs exécutant Yosemite, chacun avec une configuration différente. Tous les trois sont en place depuis une durée de trois jours à une semaine. Voici un aperçu de ce qui secda été accompli:

• Sur MacBookAir 2011 avec 4 Go de mémoire, 700 Mo alloués à secd
• Sur iMac 2008 avec 6 Go de mémoire, 2 Go alloués à secd
• Sur iMac 2011 avec 12 Go de mémoire, 4 Go alloués à secd

Sur les trois ordinateurs, secdc'est le plus grand processus en mémoire (plus grand que kernel task) et je soupçonne qu'il joue un rôle dans le ralentissement que j'ai récemment connu avec l'arrivée de Yosemite. Je sais avec certitude que le processus se développe en mémoire à des tailles démesurées et libère de la mémoire lorsque j'en ai besoin ailleurs. Le seul problème est qu'il n'est pas aussi rapide à libérer de la mémoire et la plupart du temps les performances souffrent avant que le processus ne se rende compte qu'il doit reculer.

Ma recherche sur le Web n'est pas arrivée à une conclusion solide quant à ce qu'est le processus et pourquoi il devrait être si énorme. Je suppose que je ne suis pas le seul à vivre cela. Tout conseil est apprécié.

Comme suggéré ci-dessous, cela secdconcerne le trousseau Apple. Voici les fichiers et les ports que le processus garde ouverts lorsqu'il est actif (sur MacBookAir):

/
/usr/libexec/secd
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-shm
/usr/share/icu/icudt53l.dat
/usr/lib/dyld
/private/var/run/diagnosticd/dyld_shared_cache_x86_64
/dev/null
/dev/null
/dev/null
count=2, state=0x2
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-shm
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal
/dev/random
/dev/random
/private/var/folders/z_/806bzc396cxgp4s0q17tpfwc0000gn/T/etilqs_y5BDgkbGkBV9ybF
/private/var/folders/z_/806bzc396cxgp4s0q17tpfwc0000gn/T/etilqs_Aw6Q7JhPlil3QNX
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db
/Users/.../Library/Keychains/7285EFCF-9AF6-53DD-BE44-DA1F59F96620/keychain-2.db-wal

Ce qui n'est pas clair, c'est ce que le processus fait à toute la mémoire qu'il occupe et pourquoi il se gonfle autant.

Si ce n'est pas apparent, ce n'est qu'une supposition. Mais j'espère que cela vous donne quelques pistes.

Tout d'abord, voici ce que vous pouvez comprendre à partir du nom du programme. Si vous exécutez la commande /bin/ls /usr/libexec | sort -f | egrep '.*d$'(ce imprimer tous les fichiers /usr/libexecse terminant en d), vous trouverez ftpd, hidd, networkd, systemstatsd, et beaucoup de programmes se terminent par d. Le "d" signifie "démon", ce qui signifie essentiellement un processus d'assistance qui s'exécute toujours en arrière-plan. Le sectrès probablement représente la «sécurité». Il en secdva de même du «démon de sécurité». Ce qui est logique, car vous avez dit qu'il semble que cela fonctionne avec les trousseaux.

Quel est l'intérêt des démons? Certains démons continuent de fonctionner pour effectuer des tâches en cours. hidd("démon de périphérique d'interface humaine"), par exemple, est le processus responsable de la gestion des entrées souris / clavier / pavé tactile. Certains autres démons effectuent des tâches courantes dont de nombreux autres programmes ont besoin. Les applications peuvent simplement dire au démon de faire quelque chose au lieu d'avoir du code pour le faire lui-même. Fait secdprobablement quelque chose comme ça, mais lié au trousseau.

Mais quoi exactement? Il semble qu'il ne gère pas réellement l'utilisation normale du trousseau, car j'ai toujours pu utiliser le trousseau après avoir désactivé le secdLaunchAgent.

L'inspection du LaunchAgent nous donne un indice:

Il semble que secd soit responsable de la synchronisation du trousseau avec iCloud?

Alors, que devrais-tu faire? Essayez un ou plusieurs d'entre eux:

1. Si vous n'avez pas besoin de synchroniser le trousseau iCloud, désactivez-le dans les préférences iCloud.
2. Utilisez cette launchctloption pour désactiver secd si cela ne semble pas affecter quoi que ce soit.
3. Si vous avez besoin de la synchronisation du trousseau iCloud, voyez si vous avez une tonne d'éléments de trousseau et supprimez ceux dont vous n'avez pas besoin.
4. Peut-être reconstruisez votre trousseau (créez un nouveau trousseau, déplacez-y les éléments dont vous avez besoin et déplacez-le sur l'ancien), au cas où il y aurait des artefacts inutiles dans l'ancien trousseau.

Le programme / usr / libexec / secd est fourni avec OS X et constitue un processus de sécurité normal. La documentation indique qu'elle se rapporte aux «politiques de sécurité d'exécution pour les processus». Vous pouvez inspecter les processus associés avec cette commande:ps -ef|grep sec[iud]

Sur mon Mac, je suis l'utilisateur 501, vous avez donc cette sortie pour un utilisateur connecté:

Mac:~ bmike$ ps -ef|grep sec[iud]
    0    58     1   0 Sat12PM ??         0:56.51 /usr/sbin/securityd -i
    0   117     1   0 Sat12PM ??         0:00.15 /usr/libexec/secinitd
    0   171     1   0 Sat12PM ??         0:02.24 /usr/libexec/securityd_service
  501   205     1   0 Sat12PM ??         0:11.74 /usr/libexec/secinitd
  501  2634     1   0 Tue08PM ??         0:08.26 /usr/libexec/secd

Vous pouvez voir qu'il securitydest démarré en tant que processus racine (PID 58) puis en tant qu'utilisateur (PID 205) lorsque vous vous connectez. Le réel secdeffectue le "travail" et peut être réapparu même lorsque vous ne vous déconnectez pas et ne vous connectez pas. pour déchiffrer pourquoi la vôtre utilise des ressources supplémentaires, il sera assez difficile sans creuser fsusageet quelques autres commandes de jeter un œil aux processus en cours et de regarder vos fichiers journaux. Votre meilleur pari serait de déposer un bogue auprès d'Apple, puis de documenter comment vous pouvez le faire mal se comporter - surtout si vous pouvez le reproduire après un redémarrage.

Il n'y a actuellement pas de "page de manuel" pour secdet celle pour secinitdest au mieux maigre. Le dépôt de bogues de documentation contre Apple est un moyen de demander que le manque de documentation soit corrigé.

D'après ce que je sais de ce processus (qui n'est vraiment pas une tonne), c'est qu'il a quelque chose à voir avec le trousseau du Mac. Ce que vous pouvez faire est de trouver dans le moniteur d'activité et de cliquer sur Cmd + I pour obtenir des informations à ce sujet.

Une astuce que vous pouvez essayer de faire est d'exécuter le trousseau de premiers soins en accédant à Keychain Access dans Spotlight, en ouvrant le menu "Keychain Access" et en sélectionnant l'option "Keychain First Aid" à partir de là et en suivant les instructions.

J'espère que cette astuce fonctionne!

Commencez à activer la synchronisation du trousseau iCloud mais annulez dans une autre fenêtre de dialogue.

source: https://www.reddit.com/r/hackintosh/comments/54gpmo/process_secd_always_at_95100_cpu_usage_sierra/d88v542/