securityd usando il 100% di CPU e inquinando system.log

Da quando ho eseguito l'aggiornamento a Mavericks, spesso ho i seguenti processi che utilizzano la piena potenza della CPU:

• securityd
• syslogd
• kernel_task

Immagino che securitydcontenga un bug, perché inquina /var/log/system.logcon migliaia di messaggi al secondo e il sistema non può essere seguito.

Ecco un esempio di messaggi che ricevo:

Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 44365 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---
Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 26642 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---
Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 44365 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---
Nov 11 15:55:10 localhost securityd[22]: assertion failed: 13A603: libxpc.dylib + 26642 [4554927A-9467-365C-91F1-5A116989DD7F]: 0x13
Nov 11 16:14:47 --- last message repeated 1 time ---

Credo che questo sia un problema critico, poiché rende Mac OS X estremamente lento e non risponde.

Uccidere securityidnon aiuta. Il processo viene ricreato e continua a inquinare syslogd.

Se riavvio l'intero sistema, tutto sembra a posto per un po ', prima che si ripeta lo stesso problema. Non ho ancora capito cosa scateni questo problema.

Nel mio caso, il processo di sicurezza haywire è stato causato dall'app desktop GitHub - durante il commit, i problemi di rete hanno causato un errore nell'handshake ssh. Gli impegni successivi sono andati bene. L'app GitHub è stata lasciata aperta, securityd stava riscaldando la mia CPU. La chiusura dell'app GitHub ha risolto il problema, probabilmente terminando qualcosa in securityd. Quindi la mia ipotesi è che securityd abbia qualche problema di loop infinito durante le operazioni di crittografia, forse solo con ssh e strette di mano.

Quindi, controlla se e come il tuo flusso di lavoro quotidiano può attivare securityd (accedendo al server? Github?) E isolare il problema.

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

sudo killall SecurityAgent

Questo ha funzionato ogni volta per me. Sto ancora studiando la 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 del portachiavi (è richiesta la password originale per sbloccare il portachiavi) e ho ricevuto un "ciclo infinito" di prompt sulla falsariga di "Apple Messages Agent vuole utilizzare l'elemento" login "dal tuo portachiavi .."

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

Concordo sul fatto che qualsiasi registrazione diagnostica così rapida e incontrollabile da influire sull'utilizzo di energia del computer o sulle prestazioni del computer in modo evidente dovrebbe essere considerata un errore.

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

Mavericks ha svolto un lavoro eccezionale nel esporre gli strumenti diagnostici e il consumo di energia nel tempo di tutti i processi all'utente finale interessato.

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

Avrai bisogno di un AppleID associato a una sorta di account sviluppatore, quindi puoi registrarti come sviluppatore Safari gratuitamente se non disponi già di un account abilitato per segnalare specifici bug ad Apple.

Sto vedendo lo stesso problema esatto per la seconda volta di seguito entro una settimana con gli stessi identici messaggi nella console.

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

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

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

TLDR:

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

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

Ho creato una VM usando virtualBox e questo problema è in qualche modo ricreabile. Ho creato alcuni elementi portachiavi e quando visito il sito Web a cui è destinato l'elemento portachiavi, la macchina virtuale si blocca per 1-2 minuti, quindi si libera. Può essere git-osxkeychain-helper che fa sì che il processo securityd diventi l'intero CPU.

Sembra avere qualcosa a che fare con il gestore di portachiavi. Stavo solo avendo questo e ucciso il portachiavi ed è andato via.