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.0 votes
@interestinglythere Vous avez tout à fait raison, mais la question reste de savoir comment traiter un " secd " véreux !
0 votes
@Mah Une raison typique pour laquelle les démons prennent beaucoup de mémoire est qu'ils stockent les données qu'ils travaillent (dans ce cas, le trousseau de clés) en mémoire pour améliorer la vitesse. L'hypothèse ici est que le système d'exploitation sera en mesure d'échanger rapidement la mémoire sur le disque si la mémoire est nécessaire pour des choses plus urgentes, mais il semble que cette hypothèse ne soit pas valable ici. Avez-vous beaucoup d'objets dans votre trousseau ?
0 votes
Certainement moins de 1000 éléments (tous les certificats, certificats système, logins et clés privées et publiques combinés).
0 votes
Pour information, mon disque dur fait environ 1 Mo.
2 votes
Selon le Plist secd est utilisé pour gérer le trousseau de clés du cloud et non le trousseau local.
3 votes
Je viens de découvrir : Sans
secd
en cours d'exécution, Messages me demande un mot de passe à chaque fois.0 votes
C'est intéressant : Je travaille sur différents OS, et il n'est pas courant de trouver un démon système qui n'est pas documenté. D'un point de vue de la sécurité, tout ce qui n'est pas documenté est mauvais . Vous pourriez avoir raison dans ce cas : Mah
secd
pourrait être un démon au comportement sain. Mais sans la documentation, personne ne peut juger de toute façon.1 votes
Mah : sur Maveriskc,
secd
a un VSZ = 2.4 GB, et un RSS = 3 MB.secd
a fonctionné pendant 84 s sur un système qui est opérationnel depuis 5 jours.0 votes
Je viens de trouver ce petit gars qui prend 5.35GB de mémoire sur un rMBP de 1ère génération !
0 votes
C'est ce que j'ai sur le mien. iMac avec 32 Go de mémoire, OS X Yosemite 10.10.2 ! Entrez la description de l'image ici
0 votes
Macbook Air OS Sierra 1.7GHz 4GB 128GB Même problème : ventilateurs non-stop et secd fonctionnant en arrière-plan. J'ai rétabli les valeurs par défaut de mon trousseau de clés. J'ai activé le trousseau iCloud et le processus s'est immédiatement arrêté. Si quelqu'un peut m'expliquer, j'apprécierais une réponse.