27 votes

Qu'est-ce que le processus "secd" ?

Je me demande ce que secd sous OSX Yosemite. Je suis pratiquement sûr d'avoir vu ce processus fonctionner dans des versions antérieures de MacOS, mais je ne me souviens pas qu'il ait englouti toute la mémoire disponible de manière aussi audacieuse...

J'ai trois ordinateurs qui utilisent Yosemite, chacun avec une configuration différente. Tous les trois ont été en service pendant une durée de trois jours à une semaine. Voici un aperçu de ce qui suit secd a atteint :

  • Sur un MacBookAir 2011 avec 4 Go de mémoire, 700 Mo sont alloués à l'espace de travail. secd
  • Sur un iMac 2008 avec 6GB de mémoire, 2GB alloués à secd
  • Sur un iMac 2011 avec 12GB de mémoire, 4GB alloués à secd

Sur les trois ordinateurs secd est le plus gros processus en mémoire (plus grand que kernel task ) et je soupçonne que cela joue un rôle dans le ralentissement que j'ai connu récemment avec l'arrivée de Yosemite. Je sais avec certitude que le processus s'étend en mémoire jusqu'à 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 que, la plupart du temps, les performances souffrent avant que le processus ne réalise qu'il doit se retirer.

Mes recherches sur le web n'ont pas permis d'aboutir à une conclusion solide quant à la nature du processus et à la raison pour laquelle il est si important. Je suppose que je ne suis pas le seul à connaître ce problème. Tout conseil est le bienvenu.

Comme suggéré ci-dessous secd a à voir avec le trousseau d'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 gonfle autant.

2 votes

Votre mémoire est bonne. secd court sur les Mavericks. En analyse rapide, ce démon n'est pas documenté, c'est mauvais, c'est peut-être un logiciel merdique. Ce démon est dans /usr/libexec/secd .

0 votes

@danielAzuelos Montre-t-il le même comportement cancéreux sur Mavericks ?

0 votes

@danielAzuelos Les Mac OS n'ont généralement pas beaucoup de "crapware", et je vous déconseille de sauter à cette conclusion. En fait, tout ce qui se trouve dans /System fait partie du système d'exploitation installé à l'origine, et n'est pas ajouté par un quelconque programme.

21voto

interestinglythere Points 1174

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

Tout d'abord, voici ce que vous pouvez découvrir juste à partir du nom du programme. Si vous exécutez la commande /bin/ls /usr/libexec | sort -f | egrep '.*d$' (ceci imprime tous les fichiers dans /usr/libexec se terminant par d ), vous trouverez ftpd , hidd , networkd , systemstatsd et beaucoup de programmes se terminant par d . Le "d" signifie "daemon", c'est-à-dire un processus d'aide qui fonctionne toujours en arrière-plan. Le site sec signifie très probablement "sécurité". Donc secd est le "démon de la sécurité". Ce qui est logique puisque tu as dit qu'il semblait fonctionner avec le trousseau de clés.

Quel est l'intérêt des démons ? Certains démons restent en fonctionnement pour effectuer une tâche en cours. hidd ("human interface device daemon"), par exemple, est le processus responsable de la gestion des entrées de la souris, du clavier et du pavé tactile. D'autres démons effectuent des tâches courantes dont de nombreux autres programmes ont besoin. Les applications peuvent simplement demander au démon de faire quelque chose au lieu d'avoir du code pour le faire elles-mêmes. Ainsi, secd fait probablement quelque chose comme ça, mais en rapport avec le trousseau de clés.

Mais quoi exactement ? Il semble qu'il ne gère pas vraiment l'utilisation normale du trousseau, puisque j'ai pu continuer à utiliser le trousseau après avoir désactivé l'option secd LaunchAgent.

L'inspection de l'agent de lancement nous donne un indice :

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

Que devez-vous faire ? Essayez une ou plusieurs de ces solutions :

  1. Si vous n'avez pas besoin de la synchronisation du trousseau iCloud, désactivez-la dans les préférences iCloud.
  2. Utilice launchctl de désactiver secd si cela ne semble pas affecter négativement 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. Reconstruisez peut-être votre trousseau (créez un nouveau trousseau, placez-y les éléments dont vous avez besoin et déplacez-le par-dessus l'ancien), au cas où il resterait des artefacts inutiles dans l'ancien trousseau.

0 votes

C'est un détail impressionnant. L'étape 2 doit comporter un astérisque - notez que vous avez désactivé cette fonction, car Apple y ajoute généralement une nouvelle fonctionnalité et votre Mac s'arrête alors. N'oubliez donc pas de la réactiver de temps en temps et de revenir sur la décision de désactiver un démon système.

0 votes

Encore une fois, une réponse fantastique qui explique comment faire de l'ingénierie inverse sur n'importe quel démon et pas seulement sur celui-ci qui n'est pas bien documenté.

5voto

Oskar Points 1242

Le programme /usr/libexec/secd est livré avec OS X et constitue un processus de sécurité normal. La documentation indique qu'il est lié 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, donc vous avez ce résultat 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 que securityd est lancé en tant que Root (PID 58) et ensuite en tant qu'utilisateur (PID 205) lorsque vous vous connectez. Le processus secd effectue le "travail" et peut être relancé même si vous ne vous déconnectez pas et ne vous reconnectez pas. Pour ce qui est de savoir pourquoi le vôtre utilise des ressources supplémentaires, ce sera assez difficile sans creuser dans la section fsusage et d'autres commandes permettant de jeter un coup d'œil aux processus en cours d'exécution ainsi qu'à vos fichiers journaux. Le mieux serait de signaler un bogue à Apple et de documenter la manière dont vous parvenez à obtenir un mauvais comportement, surtout si vous pouvez le reproduire après un redémarrage.

Il n'y a pas actuellement de "page de manuel" pour le programme secd et celle pour secinitd est au mieux maigre. Déposer des bugs de documentation contre Apple est une façon de demander que l'on remédie à ce manque de documentation.

3voto

yaanno Points 221

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

Une astuce que vous pouvez essayer de faire est d'exécuter le Keychain First Aid en allant sur 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 fonctionnera !

0 votes

Keychain First Aid dit que mon porte-clés va bien ! Sur les trois ordinateurs.

0 votes

Il existe une option dans El Capitan (du moins, elle existe peut-être aussi dans les versions précédentes) sous Accès au trousseau - Préférences pour Réinitialiser mon trousseau par défaut "Rétablit les paramètres d'usine par défaut et crée un nouveau trousseau de connexion vide. Votre trousseau par défaut actuel sera mis de côté, mais pas supprimé". Dès que j'ai fait cela, le securityd_service est passé de 51-53% CPU à 0-1.5%. Dès que vous faites cela, vous devez vous reconnecter à iCloud - je n'ai pas encore découvert d'autres ramifications.

1 votes

Je viens de passer de Mavericks à Sierra et j'ai constaté que le processeur secd est passé de près de 100% après avoir réinitialisé le trousseau comme vous l'avez suggéré. J'ai perdu tous mes mots de passe de sites Web enregistrés, j'ai dû me reconnecter à la synchronisation de mon calendrier, etc. mais au moins, je peux à nouveau utiliser l'ordinateur. Merci.

0voto

Nakilon Points 312

Commencez à activer la synchronisation Keychain iCloud mais annulez sur une autre fenêtre de dialogue.

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

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X