Pourquoi mon journal systemd n'est-il pas persistant lors des redémarrages?

Je rencontre un problème très étrange avec une nouvelle image Fedora 21 sur une instance Linode. Je ne peux pas le reproduire en dehors de Linode. Le problème est que mon journal systemd n'est pas persistant lors des redémarrages. Selon la documentation :

Par défaut, le journal stocke les données de journal dans / run / log / journal /. Étant donné que / run / est volatile, les données de journal sont perdues au redémarrage. Pour rendre les données persistantes, il suffit de créer / var / log / journal / où systemd-journald stockera ensuite les données.

J'ai vérifié que / var / log / journal existe et j'ai également défini Storage=persistentdans /etc/systemd/journald.conf. Le répertoire des journaux contient un tas de données:

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

Cependant, le journal ne contient que des entrées de journal depuis le dernier redémarrage du système:

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

Même si je journalctl --flushavant de redémarrer, les journaux sont perdus. Je soupçonne que c'est un problème avec l'image Fedora 21 de Linode, et j'ai ouvert un ticket d'assistance avec eux. En attendant, je continue de chercher la cause de ce problème.

Comment puis-je déboguer cela? Qu'est-ce qui pourrait provoquer cela? Que puis-je faire pour résoudre ce problème?

La raison de ce comportement est que l'identifiant de la machine /etc/machine-idchange à chaque redémarrage. Cela démarre un nouveau répertoire de journalisation sous /var/log/journal. Les anciens journaux peuvent être consultés avec la commande suivante:

journalctl --merge

Je cherche toujours la cause du changement d'ID machine. Le support Linode est conscient du problème. Je mettrai à jour cette réponse lorsque j'en saurai plus.

MISE À JOUR - La cause première du problème est simplement que Linode a mis à zéro le contenu de /etc/machine-idleurs images de système de fichiers. Le résultat est la chaîne d'événements suivante:

1. Le noyau charge et monte le système de fichiers racine en lecture seule
2. systemd, exécuté à partir du disque virtuel initial, essaie de lire à /etc/machine-idpartir du système de fichiers racine (le fichier existe mais n'a aucun contenu)
3. systemd ne peut pas lire l'identifiant de la machine, mais ne peut pas non plus en écrire un nouveau car le système de fichiers racine est monté en lecture seule
4. systemd se monte tmpfssur /etc/machine-id(Oui, apparemment, vous pouvez monter un système de fichiers sur un fichier )
5. systemd appelle systemd-machine-id-setup qui génère un identifiant machine aléatoire et le stocke dans le fichier désormais volatile/etc/machine-id
6. Le système démarre avec un identifiant de machine volatile

Vous pouvez vérifier si votre système a un identifiant de machine volatile plutôt qu'un identifiant de machine permanent en regardant la sortie de mount:

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

Le problème est facile à résoudre: il suffit d'écrire un identifiant machine persistant dans le réel /etc/machine-id . Cela est plus facile à dire qu'à faire, cependant, parce que vous ne pouvez pas Démontez à tmpfspartir /etc/machine-idd'un système en cours d' exécution. Voici les étapes que j'ai prises pour le réparer sur Linode:

1. cp /etc/machine-id /etc/machine-id.copy, puis mettez le système hors tension
2. Dans le gestionnaire Linode, accédez à l'onglet Rescue et démarrez en mode de secours
3. Accéder au système via la console Lish
4. Montez le système de fichiers racine: mount /dev/xvda /mnt
5. Déplacez la copie créée à l'étape 1 vers l'ID machine réel: mv /etc/machine-id.copy /etc/machine-id
6. Redémarrer

Telles sont les conséquences d'un identifiant de machine manquant au démarrage. J'espère que cela aidera un passant aléatoire à l'avenir.