Perché il mio diario di sistema non è persistente durante i riavvii?


8

Sto riscontrando un problema molto strano con una nuova immagine Fedora 21 su un'istanza di Linode. Non riesco a riprodurlo al di fuori di Linode. Il problema è che il mio diario di sistema non è persistente durante i riavvii. Secondo la documentazione :

Per impostazione predefinita, il journal memorizza i dati di log in / run / log / journal /. Poiché / run / è volatile, i dati di registro vengono persi al riavvio. Per rendere persistenti i dati, è sufficiente creare / var / log / journal / dove systemd-journald memorizzerà i dati.

Ho verificato che / var / log / journal esista e ho anche impostato Storage=persistentin /etc/systemd/journald.conf. La directory del registro contiene un sacco di dati:

$ du -sh /var/log/journal/
89M /var/log/journal/

Il journal, tuttavia, contiene solo voci di registro dall'ultimo riavvio del sistema:

$ journalctl --list-boots
 0 9f6a5a789dd64ec0b067140905e6da86 Thu 2015-03-19 15:08:48 GMT—Thu 2015-03-19 22:14:37 GMT

Anche se journalctl --flushprima di riavviare i registri vengono persi. Ho il sospetto che questo sia un problema con l'immagine Fedora 21 di Linode, e ho aperto un ticket di supporto con loro. Nel frattempo, continuo a cercare la causa di questo problema.

Come posso eseguire il debug di questo? Cosa potrebbe causare questo? Cosa posso fare per risolvere questo problema?

Risposte:


14

Il motivo di questo comportamento è che l'identificativo della macchina /etc/machine-idcambia a ogni riavvio. Ciò avvia una nuova directory di registrazione in /var/log/journal. I vecchi registri possono essere visualizzati con il seguente comando:

journalctl --merge

Sto ancora esaminando la causa del cambio ID macchina. Il supporto Linode è a conoscenza del problema. Aggiornerò questa risposta quando ne saprò di più.


AGGIORNAMENTO - La causa principale del problema è semplicemente che Linode ha azzerato il contenuto delle /etc/machine-idimmagini del loro filesystem. Il risultato è la seguente catena di eventi:

  1. Il kernel carica e monta il filesystem di root in sola lettura
  2. systemd, eseguito dal ramdisk iniziale, tenta di leggere /etc/machine-iddal filesystem di root (il file esiste ma ha zero contenuti)
  3. systemd non è in grado di leggere l'identificatore della macchina, ma non può nemmeno scriverne uno nuovo poiché il filesystem di root è montato in sola lettura
  4. systemd si monta tmpfssu /etc/machine-id(Sì, apparentemente puoi montare un filesystem su un file )
  5. systemd invoca systemd-machine-id-setup che genera un id-macchina casuale e lo memorizza nell'ora-volatile/etc/machine-id
  6. Il sistema si avvia con un identificativo macchina volatile

Puoi verificare se il tuo sistema ha un ID macchina volatile, anziché permanente, osservando l'output di mount:

$ mount | grep machine-id
tmpfs on /etc/machine-id type tmpfs (ro,mode=755)

Il problema è facile da risolvere: è sufficiente scrivere un ID macchina persistente sul reale /etc/machine-id . Questo è più facile a dirsi che a farsi, tuttavia, perché non è possibile smontare tmpfsda /etc/machine-idun sistema in esecuzione. Questi sono i passaggi che ho seguito per risolverlo su Linode:

  1. cp /etc/machine-id /etc/machine-id.copy, quindi spegnere il sistema
  2. In Linode Manager, vai alla scheda Rescue e avvia in modalità di salvataggio
  3. Accedi al sistema tramite la console Lish
  4. Montare il filesystem di root: mount /dev/xvda /mnt
  5. Sposta la copia creata nel passaggio 1 sull'ID macchina reale: mv /etc/machine-id.copy /etc/machine-id
  6. Reboot

Tali sono le conseguenze di un ID macchina mancante all'avvio. Spero che questo possa aiutare un passante casuale in futuro.


5
Puoi cambiare / etc / machine-id senza salvare / riavviare usando un mount bind di /:mkdir /tmp/mnt; mount --bind / /tmp/mnt; cp -a /etc/machine-id /tmp/mnt/etc/; umount /tmp/mnt
rudimeier
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.