Cos'è il processo "secd"?


19

Mi chiedo quale secdprocesso faccia con OSX Yosemite. Sono abbastanza sicuro di aver visto questo processo in esecuzione nelle precedenti versioni di MacOS, ma non ricordo che divorasse tutta la memoria disponibile in modo così audace ...

Ho tre computer con Yosemite, ognuno con una configurazione diversa. Tutti e tre sono attivi da tre giorni a una settimana. Ecco un riassunto di ciò che secdha raggiunto:

  • Su MacBookAir 2011 con 4 GB di memoria, a 700 MB assegnati secd
  • Su iMac 2008 con 6 GB di memoria, 2 GB assegnati a secd
  • Su iMac 2011 con 12 GB di memoria, 4 GB assegnati a secd

Su tutti e tre i computer secdc'è il più grande processo in memoria (più grande di kernel task) e sospetto che abbia un ruolo nel rallentamento che ho recentemente sperimentato con l'arrivo di Yosemite. So per certo che il processo si espande nella memoria a dimensioni eccessive e libera la memoria quando ne ho bisogno altrove. L'unico problema è che non è così veloce nel liberare memoria e il più delle volte le prestazioni subiscono prima che il processo si renda conto che deve ritirarsi.

La mia ricerca sul Web non è giunta a una conclusione solida per quanto riguarda il processo e perché dovrebbe essere così grande. Immagino di non essere il solo a sperimentarlo. Qualsiasi consiglio è apprezzato.

Come suggerito di seguito secdha a che fare con Apple Keychain. Ecco i file e le porte che il processo mantiene aperti quando attivi (su 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

Ciò che non è chiaro è cosa fa il processo a tutta la memoria che occupa e perché si gonfia così tanto.


2
La tua memoria è giusta. secdcorre su Mavericks. All'analisi veloce, questo demone non è documentato, questo è male, questo potrebbe essere un pezzo di merda. Questo demone è dentro /usr/libexec/secd.
dan

@danielAzuelos Mostra lo stesso comportamento canceroso su Mavericks?
retrografia

2
Secondo il Plist secd viene utilizzato per gestire il portachiavi cloud non quello locale.
Ruskes,

2
Appena scoperto: senza secdcorrere, Messaggi mi chiede una password ogni volta.
interessante

1
→ Mah: su Maveriskc, secdha un VSZ = 2,4 GB e un RSS = 3 MB. secdha funzionato per 84 secondi su un sistema attivo e funzionante da 5 giorni.
dan

Risposte:


20

Se non è evidente, questa è solo una supposizione. Ma spero che ti dia qualche vantaggio.

Innanzitutto, ecco cosa puoi capire solo dal nome del programma. Se si esegue il comando /bin/ls /usr/libexec | sort -f | egrep '.*d$'(questa stampa tutti i file /usr/libexecche terminano in d), troverete ftpd, hidd, networkd, systemstatsd, e un sacco di programmi che terminano in d. La "d" sta per "demone", che sostanzialmente significa un processo di supporto che viene sempre eseguito in background. Il secmolto probabilmente sta per "sicurezza". Così secdè il "demone della sicurezza". Il che ha senso perché hai detto che sembra funzionare con i portachiavi.

Qual è il punto dei demoni? Alcuni demoni rimangono in esecuzione per eseguire alcune attività in corso. hidd("demone dispositivo interfaccia umana"), ad esempio, è il processo responsabile della gestione dell'input da mouse / tastiera / trackpad. Alcuni altri demoni svolgono alcune attività comuni di cui hanno bisogno molti altri programmi. Le app possono semplicemente dire al demone di fare qualcosa invece di avere il codice per farlo da soli. Cosìsecd probabilmente fa qualcosa di simile, ma legato al portachiavi.

Ma cosa esattamente? Sembra che in realtà non gestisca il normale utilizzo del portachiavi, poiché sono stato ancora in grado di utilizzare il portachiavi dopo aver disabilitato ilsecd LaunchAgent.

Ispezionare LaunchAgent ci dà un indizio:

Sembra che secd sia responsabile della sincronizzazione del portachiavi con iCloud?

Quindi cosa dovresti fare? Prova uno o più di questi:

  1. Se non hai bisogno della sincronizzazione del portachiavi iCloud, disattivalo nelle preferenze di iCloud.
  2. Utilizzare launchctlper disabilitare secd se non sembra influire negativamente su nulla.
  3. Se hai bisogno di sincronizzare il portachiavi iCloud, vedi se hai un sacco di elementi portachiavi e rimuovi quelli che non ti servono.
  4. Forse ricostruisci il tuo portachiavi (crea un nuovo portachiavi, sposta gli oggetti di cui hai bisogno e spostalo su quello più vecchio), nel caso in cui nel vecchio portachiavi siano rimasti artefatti non necessari.

Questo è un dettaglio fantastico. Il passaggio 2 dovrebbe avere un asterisco: prendi nota che hai disabilitato questo dato che Apple di solito aggiunge alcune nuove funzionalità a questo e il tuo Mac si romperà quando ciò accade, quindi ricorda di riaccenderlo di tanto in tanto e rivedere la decisione di disabilitare un demone di sistema.
bmike

Ancora una volta: una risposta fantastica che spiega come decodificare qualsiasi demone e non solo questo che non è ben documentato.
bmike

5

Il programma / usr / libexec / secd viene fornito come parte di OS X ed è un normale processo di sicurezza. La documentazione afferma che si riferisce alle "politiche di sicurezza runtime per i processi". È possibile controllare i processi associati con questo comando:ps -ef|grep sec[iud]

Sul mio Mac, sono l'utente 501, quindi hai questo output per un utente connesso:

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

Si può vedere che securitydviene avviato come root (PID 58) e quindi come processo utente (PID 205) quando si effettua l'accesso. L'attuale secdesegue il "lavoro" e può essere rigenerato anche quando non ci si disconnette e si esegue l'accesso. per decifrare perché il tuo sta usando risorse extra, sarà piuttosto difficile senza scavarefsusage e alcuni altri comandi per sbirciare i processi in esecuzione e guardare oltre i file di registro. La soluzione migliore sarebbe quella di presentare un bug con Apple e quindi documentare come si può ottenere un comportamento anomalo, soprattutto se è possibile riprodurlo dopo un riavvio.

Al momento non esiste una "pagina man" per secde quella per secinitdè al massimo scarsa. La presentazione di bug relativi alla documentazione contro Apple è un modo per chiedere di porre rimedio alla mancanza di documentazione.


3

Da quello che so di quel processo (che in realtà non è una tonnellata) è che ha qualcosa a che fare con il Keychain del Mac. Quello che puoi fare è trovare in Activity Monitor e fare clic su Cmd + I per ottenere le informazioni a riguardo.

Un suggerimento che puoi provare a fare è eseguire il Pronto soccorso portachiavi andando su Accesso portachiavi in ​​Spotlight, aprendo il menu "Accesso portachiavi" e selezionando l'opzione "Pronto soccorso portachiavi" da lì e seguire le indicazioni.

Spero che la mancia funzioni!


Keychain First Aid dice che il mio portachiavi va bene! Su tutti e tre i computer.
retrografia

C'è un'opzione in El Capitan (almeno, potrebbe esserci anche nelle versioni precedenti) in Accesso portachiavi - Preferenze per ripristinare il mio Kechain predefinito "Ripristina le impostazioni predefinite di fabbrica e crea un nuovo portachiavi" login "vuoto. Il tuo portachiavi predefinito corrente sarà essere spostato da parte, ma non cancellato ". Non appena l'ho fatto, securityd_service è passato dal 51-53% della CPU allo 0-1,5%. Non appena lo fai, devi ripetere l'accesso a iCloud: non ho ancora scoperto altre ramificazioni.
Oskar Austegard,

1
Ho appena aggiornato da Mavericks a Sierra e ho scoperto che la seconda CPU è passata da quasi il 100% dopo aver ripristinato il portachiavi come hai suggerito. Ho perso tutte le password del mio sito Web salvato, ho dovuto accedere nuovamente alla sincronizzazione del mio calendario, ecc., Ma almeno posso riutilizzare il computer. Grazie.
Walter Nissen,

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.