Warum ist mein systemd-Journal bei Neustarts nicht dauerhaft?

Ich habe ein sehr seltsames Problem mit einem neuen Fedora 21-Image auf einer Linode-Instanz. Ich kann es nicht außerhalb von Linode reproduzieren. Das Problem ist, dass mein systemd-Journal bei Neustarts nicht dauerhaft ist. Laut Dokumentation :

Standardmäßig speichert das Journal Protokolldaten in / run / log / journal /. Da / run / flüchtig ist, gehen die Protokolldaten beim Neustart verloren. Um die Daten dauerhaft zu erhalten, reicht es aus, / var / log / journal / zu erstellen, in dem systemd-journald die Daten speichert.

Ich habe überprüft, ob / var / log / journal vorhanden ist, und ich habe auch Storage=persistentin /etc/systemd/journald.conf festgelegt. Das Protokollverzeichnis enthält eine Reihe von Daten:

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

Das Journal enthält jedoch nur Protokolleinträge seit dem letzten Systemneustart:

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

Auch wenn ich journalctl --flushvor dem Neustart die Protokolle verloren gehe. Ich vermute, dass dies ein Problem mit Linodes Fedora 21-Image ist, und ich habe mit ihnen ein Support-Ticket geöffnet. In der Zwischenzeit suche ich weiter nach der Ursache für dieses Problem.

Wie kann ich das debuggen? Was könnte das verursachen? Was kann ich tun, um dies zu beheben?

Der Grund für dieses Verhalten ist, dass sich die Computerkennung /etc/machine-idbei jedem Neustart ändert. Dies startet ein neues Protokollierungsverzeichnis unter /var/log/journal. Alte Protokolle können mit dem folgenden Befehl angezeigt werden:

journalctl --merge

Ich untersuche immer noch die Ursache für die Änderung der Maschinen-ID. Die Linode-Unterstützung ist sich des Problems bewusst. Ich werde diese Antwort aktualisieren, wenn ich mehr weiß.

UPDATE - Die Hauptursache des Problems ist einfach, dass Linode den Inhalt /etc/machine-idvon ihren Dateisystem-Images auf Null gesetzt hat . Das Ergebnis ist die folgende Ereigniskette:

1. Der Kernel lädt das schreibgeschützte Root-Dateisystem und stellt es bereit
2. systemd, wird von der anfänglichen Ramdisk ausgeführt und versucht, /etc/machine-idaus dem Root-Dateisystem zu lesen (die Datei existiert, hat aber keinen Inhalt).
3. systemd kann die Maschinen-ID nicht lesen, aber auch keine neue schreiben, da das Root-Dateisystem schreibgeschützt gemountet ist
4. systemd Halterungen tmpfsauf /etc/machine-id(Ja, anscheinend können Sie ein Dateisystem auf eine Datei einbinden )
5. systemd ruft das systemd-machine-id-setup auf, das eine zufällige Maschinen-ID generiert und im now-volatile speichert/etc/machine-id
6. Das System startet mit einer flüchtigen Maschinenkennung

Sie können überprüfen, ob Ihr System eine flüchtige und keine permanente Maschinen-ID hat, indem Sie die Ausgabe von mount:

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

Das Problem ist leicht zu beheben: Schreiben Sie einfach eine dauerhafte Maschinen-ID in die reale /etc/machine-id . Das ist leichter gesagt als getan, aber da kann man nicht Aushängen tmpfsvon /etc/machine-idauf einem laufenden System. Dies sind die Schritte, die ich unternommen habe, um das Problem auf Linode zu beheben:

1. cp /etc/machine-id /etc/machine-id.copySchalten Sie dann das System aus
2. Wechseln Sie im Linode Manager zur Registerkarte Rettung und starten Sie den Rettungsmodus
3. Greifen Sie über die Lish-Konsole auf das System zu
4. Hängen Sie das Root-Dateisystem ein: mount /dev/xvda /mnt
5. Verschieben Sie die in Schritt 1 erstellte Kopie in die tatsächliche Maschinen-ID: mv /etc/machine-id.copy /etc/machine-id
6. Starten Sie neu

Dies sind die Folgen einer fehlenden Maschinen-ID beim Booten. Ich hoffe, dass dies in Zukunft einem zufälligen Passanten helfen wird.