securityd utilizzando CPU al 100% e system.log inquinante

Nel mio caso, il processo securityd haywire è stato causato dall'app desktop GitHub - durante il commit, i problemi di rete hanno causato un errore nell'handshake ssh. I commit successivi sono andati bene. L'app GitHub è stata lasciata aperta, securityd stava surriscaldando la mia CPU. L'uscita dall'app GitHub ha risolto il problema, probabilmente chiudendo qualcosa in securityd. Quindi la mia ipotesi è che securityd abbia qualche problema di loop infinito durante le operazioni di crittografia, magari solo con ssh e handshake.

Quindi, controlla se e in che modo il tuo flusso di lavoro giornaliero può attivare securityd (accesso al server? github?) e isolare il problema.

È possibile alleviare temporaneamente il problema riavviando SecurityAgent utilizzando il seguente comando di terminale:

sudo killall SecurityAgent

Questo ha funzionato ogni volta per me. Sto ancora indagando sulla causa principale.

Per quanto ne so, questo è stato attivato passando a un altro account utente in cui avevo dovuto reimpostare la password poiché avevo dimenticato la password originale. Ciò ha causato diversi errori Keychain (password originale richiesta per sbloccare il portachiavi) e ho ricevuto un "ciclo infinito" di prompt lungo le linee di "Apple Messages Agent vuole utilizzare l'elemento" login "dal tuo portachiavi .."

La risoluzione dei problemi relativi alla causa effettiva potrebbe essere problematica poiché XPC è un protocollo di comunicazione tra processi generico e solo carichi su richiesta. Il software Apple utilizza questo sottosistema come qualsiasi programma di terze parti, quindi potrebbe essere colpa di Apple o potrebbe essere qualcosa che si sta eseguendo e il problema principale è che non si ha un modo semplice per sapere quale programma sta causando il pesante carico di registrazione (e forse un pesante carico di lavoro legittimo e anche solo la registrazione).

Sono d'accordo sul fatto che qualsiasi registrazione diagnostica così rapida e incontrollabile da influenzare notevolmente l'utilizzo energetico del computer o le prestazioni del computer dovrebbe essere considerata un errore.

Il modo più produttivo per affrontare questo è in realtà per documentare il problema e segnalare questo come un bug ad Apple.

Mavericks ha svolto un lavoro stellare nell'esporre sia gli strumenti diagnostici che l'utilizzo di energia nel tempo di tutti i processi all'utente finale interessato.

• Apri Risparmio Energia, seleziona Energia e ordina per Impatto Energia Media - scatta una foto della finestra che elabora i registri di utilizzo dell'ultimo giorno.
• Seleziona la vista CPU, cerca securityd , selezionalo nell'elenco delle attività attive e poi "Esegui diagnostica sistema ..." dal menu Visualizza o dall'ingranaggio nella barra degli strumenti.
• Invia la foto e il rapporto diagnostico compresso ad Apple all'indirizzo link

Avrai bisogno di un AppleID associato ad un qualche tipo di account sviluppatore, quindi puoi registrarti gratuitamente come sviluppatore di Safari se non hai già un account abilitato per segnalare bug specifici ad Apple.

Rivedo lo stesso identico problema per la seconda volta di seguito in una settimana con gli stessi identici messaggi nella console.

Per me, il riavvio di solito risolve il problema (la prima volta ho dovuto forzare l'arresto perché la macchina non rispondeva). E come te, devo ancora trovare il trigger che avvia i messaggi.

Il monitor dell'attività non è il colpevole, di solito sono avvisato dal fatto che il fan impazzisce, quindi avvio il monitor dell'attività solo per vedere sia syslogd che securityd che usano circa il 90% della CPU.

Penso che questo potrebbe essere un bug molto più vecchio di Mavericks. Non sono sicuro di avere lo stesso problema come te perché non ho mai controllato il mio syslog , ma ho avuto securityd che ha consumato CPU e RAM. Ho usato una vecchia soluzione del 2007 (per Leopard?).

tldr:

sudo mv /var/db/CodeEquivalenceDatabase /var/db/CodeEquivalenceDatabase.old

quindi riavvia. Sentiti libero di cancellare il vecchio file in seguito, poiché OS X ne crea automaticamente uno nuovo.

Ho creato una macchina virtuale usando virtualBox e questo problema è in qualche modo riconducibile. Ho creato alcuni oggetti portachiavi e quando visito il sito web a cui è destinato l'oggetto portachiavi, la VM si blocca per un buon 1-2 minuti, quindi si libera. Potrebbe essere git-osxkeychain-helper che fa sì che il processo securityd mangi l'intera CPU.

Sembra che abbia qualcosa a che fare con il keychain manager. Stavo solo avendo questo e ucciso portachiavi e se ne andò.