Blocco del debug: systemd perde i miei registri

Da quando ho "aggiornato" su systemd su Arch Linux, continuo a perdere i log quando si verifica un blocco imprevisto. Ho riscontrato lo stesso problema di perdita del registro un mese fa e ho appena risolto il problema. Ci sono anche altre conferme indipendenti .

Situazione:

• Mentre facevo alcune cose in Java e con utility legate alla rete, ho visto che KDE (l'orologio) era bloccato. La ventola della CPU divenne rumorosa e il calore aumentava. Il puntatore del mouse potrebbe comunque essere spostato.
• Ho provato a ssh da un'altra macchina (fallito a causa di "nessuna route verso l'host")
• Ho aspettato qualche minuto, forse il cane da guardia dell'NMI potrebbe uccidere l'attività offensiva. Niente da fare.
• Ctrl+ Alt+ F1non ha funzionato neanche dopo SysRq+R
• Poiché i passaggi precedenti non hanno funzionato, ho deciso di emettere il REI della sequenza SysRq. Dopo E, lo schermo è diventato nero, ma nessuna console neanche. Neanche dopo SysRq+K
• Quindi, questa sessione sembra essere persa, l'unica cosa che si può fare è raccogliere informazioni di debug. Guardando Wikipedia , ho deciso di premere SysRq+ d(mostra i blocchi bloccati) tra alcuni altri.
• Dopo aver premuto SysRq+ Sho atteso un secondo, quindi ho riavviato con SysRq+ B.
• Dopo il riavvio e l'accesso a una console, non ho visto alcuna traccia di crash. La voce registrata più di recente è stata dall'uso di Wireshark, ma mancavano ancora 45 minuti.

(Stavo eseguendo Linux v3.8-rc5-218-ga56e160 btw)

Quindi, come posso assicurarmi che i miei log vengano conservati quando si riavvia in modo anomalo a causa di un blocco?

Così ho chiesto sul canale IRC #systemd e si scopre che journald (il demone logging di systemd) non scarica periodicamente i log su disco. Ciò significa che i tuoi registri sono sempre a rischio in qualsiasi momento.

L'invio SIGUSR2ai journaldlog causa la scrittura su disco, ma se lo fai più volte, verranno creati molti file. (l'opzione è in realtà descritta come "rotazione del registro").

Alla fine, ho deciso di seguire un altro suggerimento: usare un demone syslog dedicato per raccogliere i log del kernel. Come è stato suggerito rsyslog (e ne avevo già esperienza), ho esplorato ulteriormente questa opzione. Ho scritto alcuni dettagli in più su Arch Wiki sull'uso di rsyslog.

L'idea è di eseguire rsyslog, raccogliendo solo i dati dalla funzione del kernel. Mentre rsyslog legge /proc/kmsg(che consente solo un singolo lettore) e journald legge /dev/kmsg(sono consentiti più lettori), non è possibile che i demoni perdano i registri (molto importante per me!). Configurare rsyslog per scrivere i messaggi del kernel in un file e assicurarsi che questo file sia ruotato per evitare di consumare spazio su disco.

Questa soluzione non è perfetta:

• Altri registri (ad esempio, da NetworkManager) vanno persi. Questo potrebbe essere risolto inoltrando più log da syslog a journald (questo significa duplicazione!)
• Duplicazione di registri. I messaggi del kernel sono scritti in due file. Questo non è un problema, in generale il numero di registri è piccolo e si preferirebbe avere più copie dei registri che nessuno. Puoi anche usare strumenti veloci come grepsul singolo file di registro o più lenti, ma più elaborati journalctl.

Esiste un elemento TODO per scaricare i log più frequentemente, ma non è ancora abbastanza affidabile:

journal: invia messaggi marker ogni tanto, e sincronizza immediatamente con fdatasync () in seguito, per avere sincronizzazioni orarie garantite.

Ora, si spera, systemd / journald avrà un'opzione per scrivere i log su disco, ma nel frattempo possiamo combinare strumenti per raggiungere l'obiettivo.

Ci sono due aggiornamenti:

1. Ora, si spera, systemd / journald avrà un'opzione per scrivere i log su disco, ma nel frattempo possiamo combinare strumenti per raggiungere l'obiettivo.

C'è un'opzione --sync:

Chiede al demone journal di scrivere tutti i dati journal non ancora scritti nel file system di supporto e sincronizzare tutti i journal. Questa chiamata non viene restituita fino al completamento dell'operazione di sincronizzazione. Questo comando garantisce che tutti i messaggi di registro scritti prima della sua chiamata siano archiviati in modo sicuro sul disco nel momento in cui ritorna.

--syncdisponibile da v228:

journalctl ha ottenuto un nuovo switch "--sync" che chiede al demone journal di scrivere sul disco tutti i messaggi di registro finora non scritti e sincronizzare i file, prima di tornare.

2. Si scopre che journald (il demone logging di systemd) non scarica periodicamente i log su disco. Ciò significa che i tuoi registri sono sempre a rischio in qualsiasi momento.

man journald.conf(5) dice:

SyncIntervalSec =

Il timeout prima di sincronizzare i file journal sul disco. Dopo la sincronizzazione, i file journal vengono posizionati nello stato OFFLINE. Si noti che la sincronizzazione viene eseguita incondizionatamente immediatamente dopo la registrazione di un messaggio di registro con priorità CRIT, ALERT o EMERG. Questa impostazione si applica quindi solo ai messaggi dei livelli ERR, WARNING, AVVISO, INFO, DEBUG. Il timeout predefinito è 5 minuti.

SyncIntervalSec=disponibile da v199:

journald ora scaricherà esplicitamente i file journal sul disco al più tardi 5 minuti dopo ogni scrittura. Il file verrà quindi contrassegnato anche offline fino alla successiva scrittura. Ciò dovrebbe aumentare l'affidabilità in caso di incidente. Il ritardo di sincronizzazione può essere configurato tramite SyncIntervalSec = in journald.conf.

Guarda anche:

journald: spedire SIGTERM / SIGINT con una priorità bassa

Assicuriamoci di elaborare tutti i dati dei registri in coda prima di uscire, in modo da non perdere inutilmente i messaggi durante lo spegnimento.