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

19

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.

macos mavericks yosemite memory daemons rétrographie
la source
2
Votre mémoire est bonne. secdfonctionne sur Mavericks. En analyse rapide, ce démon n'est pas documenté, c'est mauvais, cela pourrait être un morceau de crapware. Ce démon est dans /usr/libexec/secd.
dan
@danielAzuelos Montre-t-il le même comportement cancéreux sur Mavericks?
rétrographie
2
Selon le Plist, secd est utilisé pour gérer le trousseau cloud et non le trousseau local.
Ruskes
2
Je viens de découvrir: sans secdcourir, Messages me demande à chaque fois un mot de passe.
intéressant de noter que
1
→ Mah: sur Maveriskc, secda un VSZ = 2,4 Go et un RSS = 3 Mo. secda fonctionné pendant 84 s sur un système opérationnel depuis 5 jours.
dan

Réponses:

20

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.
fait intéressant
la source
C'est un détail génial. L'étape 2 devrait avoir un astérisque - notez que vous l'avez désactivé car Apple y ajoutera généralement une nouvelle fonctionnalité et votre Mac s'arrêtera lorsque cela se produira, alors n'oubliez pas de le réactiver de temps en temps et de revoir la décision de désactiver un démon système.
bmike
Encore une fois - une réponse fantastique qui explique comment désosser n'importe quel démon et pas seulement celui qui n'est pas bien documenté.
bmike
5

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é.

bmike
la source
3

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!

jaller200
la source
Porte-clés First Aid dit que mon trousseau va bien! Sur les trois ordinateurs.
rétrographie
Il y a une option dans El Capitan (au moins, peut-être aussi dans les versions précédentes) sous Accès au trousseau - Préférences pour réinitialiser ma Kechain par défaut "Rétablit les paramètres par défaut et crée un nouveau trousseau" de connexion "vide. Votre trousseau par défaut actuel sera être mis de côté, mais pas supprimé ". Dès que j'ai fait cela, securityd_service est passé de 51-53% CPU à 0-1,5%. Dès que vous le faites, vous devez vous reconnecter à iCloud - je n'ai pas encore découvert d'autres ramifications.
Oskar Austegard
1
Je viens de passer de Mavericks à Sierra et j'ai constaté que le processeur secd était passé de près de 100% après la réinitialisation du trousseau comme vous l'avez suggéré. J'ai perdu tous mes mots de passe de site Web enregistrés, j'ai dû me reconnecter à la synchronisation de mon calendrier, etc., mais au moins je peux utiliser à nouveau l'ordinateur. Merci.
Walter Nissen du