Che cos'è "secd"?

Question

Che cos'è "secd"?

#1 da (17 voti)
#2 da (5 voti)
#3 da (3 voti)
#4 da (0 voti)

14

Mi chiedo quale sia il processo secd sotto OSX Yosemite. Sono abbastanza sicuro di aver visto questo processo in esecuzione nelle versioni precedenti di MacOS, ma non ricordo di aver inghiottito tutta la memoria disponibile in modo così audace ...

Ho tre computer con Yosemite, ognuno con una configurazione diversa. Tutti e tre sono stati attivi per una durata da tre giorni a una settimana. Ecco una riduzione di ciò che secd ha ottenuto:

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

Su tutti e tre i computer secd è il più grande processo in memoria (maggiore di kernel task ) e ho il sospetto che giochi un ruolo nel rallentamento che ho sperimentato di recente con l'arrivo di Yosemite. So per certo che il processo si espande nella memoria di dimensioni eccessive e libera la memoria quando ne ho bisogno da qualche altra parte. L'unico problema è che non è così veloce nel liberare memoria e la maggior parte delle volte le prestazioni subiscono prima che il processo realizzi che deve ritirarsi.

La mia ricerca sul Web non è giunta a una solida conclusione su quale sia il processo e sul perché dovrebbe essere così grande. Immagino di non essere l'unico a sperimentarlo. Qualche suggerimento è apprezzato.

Come suggerito sotto secd ha a che fare con Apple Keychain. Ecco i file e le porte che il processo mantiene aperto quando attivo (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 è ciò che il processo fa a tutta la memoria che occupa e perché si gonfia così tanto.

memory macos mavericks yosemite daemons

posta retrography 07.12.2014 - 22:01

fonte

4 risposte

5

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

Sul mio Mac, sono un utente 501, quindi hai questo risultato per un utente che ha effettuato l'accesso:

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

Puoi vedere che securityd viene avviato come root (PID 58) e quindi come un utente (PID 205) processo quando effettui il login. La percentuale effettivasecd esegue il "lavoro" e può essere rigenerato anche quando non si esegue il logout e in. Per decifrare il perché si utilizzano risorse extra, sarà piuttosto difficile senza dover scavare in fsusage e alcuni altri comandi per dare un'occhiata a eseguire i processi e controllare i file di registro. La soluzione migliore sarebbe quella di archiviare un bug con Apple e quindi documentare come si può comportare un comportamento anomalo, specialmente se è possibile riprodurlo dopo un riavvio.

Al momento non esiste una "pagina man" per secd e quella per secinitd è al massimo magro. Archiviare bug di documentazione contro Apple è un modo per chiedere che sia rimossa la mancanza di documentazione.

risposta data 11.12.2014 - 22:16

fonte

3

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

Un suggerimento che puoi provare è eseguire il First Key di Keychain accedendo a Keychain Access in Spotlight, aprendo il menu "Accesso Portachiavi" e selezionando l'opzione "Keychain First Aid" da lì e segui le istruzioni.

Spero che questo tip funzioni!

risposta data 07.12.2014 - 22:25

fonte

0

Inizia a attivare la sincronizzazione iCloud Portachiavi ma cancella su un'altra finestra di dialogo.

fonte: link

risposta data 21.02.2017 - 17:56

fonte

Leggi altre domande sui tag memory macos mavericks yosemite daemons

Cambia il profilo del terminale corrente Perché iChat potrebbe non connettersi dopo l'aggiornamento a Lion?

score 17 · Accepted Answer

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

Per prima cosa, ecco cosa puoi capire solo dal nome del programma. Se esegui il comando /bin/ls /usr/libexec | sort -f | egrep '.*d$' (questo stampa tutti i file in /usr/libexec che termina con d ), troverai ftpd , hidd , networkd , systemstatsd e molti programmi che terminano in d . La "d" sta per "demone", che in pratica significa un processo di supporto che viene sempre eseguito in background. Il sec molto probabilmente sta per "sicurezza". Quindi secd è il "demone di sicurezza". Il che ha senso perché hai detto che sembra che funzioni con i portachiavi.

Qual è il punto dei demoni? Alcuni demoni stanno correndo per svolgere qualche compito in corso. hidd ("demone dispositivo di interfaccia umana"), ad esempio, è il processo responsabile della gestione dell'input mouse / tastiera / trackpad. Alcuni altri demoni svolgono alcuni compiti comuni a cui molti altri programmi hanno bisogno. Le app possono semplicemente dire al daemon di fare qualcosa invece di avere il codice per farlo da soli. Quindi secd probabilmente fa qualcosa del genere, ma in relazione al portachiavi.

Ma cosa esattamente? Sembra che in realtà non gestisca il normale utilizzo del portachiavi, dal momento che ero ancora in grado di utilizzare il portachiavi dopo aver disabilitato il secd 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:

Se non hai bisogno della sincronizzazione del portachiavi iCloud, disattivala nelle preferenze di iCloud.
Utilizza launchctl per disabilitare secd se non sembra influire negativamente su qualcosa.
Se hai bisogno della sincronizzazione del portachiavi iCloud, controlla se hai un sacco di elementi portachiavi e rimuovi quelli che non ti servono.
Forse ricostruisci il tuo portachiavi (crea un nuovo portachiavi, sposta gli elementi necessari in esso e spostalo su quello più vecchio), nel caso in cui ci siano degli artefatti non necessari rimasti nel vecchio portachiavi.