Débogage du verrouillage - systemd perd mes journaux

Depuis que j'ai «mis à niveau» vers systemd sur Arch Linux, je continue de perdre des journaux lorsqu'un blocage inattendu se produit. J'ai rencontré le même problème de perte de journal il y a un mois et je l'ai à nouveau rencontré. Il existe également d'autres confirmations indépendantes .

Situation:

• En faisant des choses en Java et avec des utilitaires liés au réseau, j'ai vu que KDE (l'horloge) était figé. Le ventilateur du processeur est devenu bruyant et la chaleur montait. Le pointeur de la souris peut toujours être déplacé.
• J'ai essayé de ssh à partir d'une autre machine (échec en raison de "pas de route vers l'hôte")
• J'ai attendu quelques minutes, peut-être que le chien de garde NMI pourrait tuer la tâche incriminée. Pas de dé.
• Ctrl+ Alt+ F1n'a pas fonctionné non plus, même après SysRq+R
• Étant donné que les étapes ci-dessus n'ont pas fonctionné, j'ai décidé d'émettre la séquence SysRq REI. Après E, l'écran est devenu noir, mais pas de console non plus. Pas même après SysRq+K
• Donc, cette session semble être perdue, la seule chose qui peut être faite est de collecter des informations de débogage. En regardant Wikipédia , j'ai décidé d'appuyer sur SysRq+ d(afficher les verrous maintenus) parmi d'autres.
• Après avoir appuyé sur SysRq+, Sj'ai attendu une seconde, puis j'ai redémarré avec SysRq+ B.
• Après avoir redémarré et connecté à une console, je n'ai vu aucune trace de crash. L'entrée la plus récemment enregistrée concernait l'utilisation de Wireshark, mais il restait un écart de 45 minutes.

(J'utilisais Linux v3.8-rc5-218-ga56e160 btw)

Alors, comment puis-je m'assurer que mes journaux sont conservés lors d'un redémarrage anormal en raison d'un blocage?

J'ai donc demandé sur le canal IRC #systemd et il s'avère que journald (le démon de journalisation de systemd) ne vide pas du tout les journaux sur le disque. Cela signifie que vos journaux sont toujours menacés à tout moment.

L'envoi SIGUSR2vers les journaldjournaux entraîne l'écriture sur le disque, mais si vous effectuez cette opération plusieurs fois, de nombreux fichiers seront créés. (l'option est en fait décrite comme "rotation du journal").

En fin de compte, j'ai décidé d'aller avec une autre suggestion: utiliser un démon syslog dédié pour collecter les journaux du noyau. Comme rsyslog a été suggéré (et je l'avais déjà expérimenté), j'ai exploré cette option plus en détail. J'ai écrit plus de détails dans l' Arch Wiki sur l'utilisation de rsyslog.

L'idée est d'exécuter rsyslog, en ne collectant que les données de l'installation du noyau. Comme rsyslog lit /proc/kmsg(qui ne permet qu'un seul lecteur) et journald lit /dev/kmsg(plusieurs lecteurs autorisés), il n'y a aucun moyen que les démons perdent les journaux (très important pour moi!). Configurez rsyslog pour écrire des messages du noyau dans un fichier et assurez-vous que ce fichier est tourné pour éviter de consommer votre espace disque.

Cette solution n'est pas parfaite:

• D'autres journaux (par exemple, de NetworkManager) sont perdus. Cela pourrait être résolu en transmettant plus de journaux de syslog à journald (cela signifie une duplication!)
• Duplication des journaux. Les messages du noyau sont écrits dans deux fichiers. Ce n'est pas un problème, en général, le nombre de journaux est petit et vous préférez avoir plus de copies des journaux qu'aucun. Vous pouvez également utiliser des outils rapides comme grepsur le fichier journal unique ou le plus lent, mais plus sophistiqué journalctl.

Il existe un élément TODO pour vider les journaux plus fréquemment, mais ce n'est toujours pas assez fiable:

journal: envoyez de temps en temps des messages de marqueur et synchronisez immédiatement avec fdatasync () par la suite, afin d'avoir des synchronisations garanties toutes les heures.

Maintenant, espérons que systemd / journald aura une option pour écrire les journaux sur le disque, mais en attendant, nous pouvons combiner des outils pour atteindre l'objectif.

Il y a deux mises à jour:

1. Maintenant, j'espère que systemd / journald aura la possibilité d'écrire les journaux sur le disque, mais en attendant, nous pouvons combiner des outils pour atteindre l'objectif.

Il y a une option --sync:

Demande au démon de journal d'écrire toutes les données de journal non écrites dans le système de fichiers de sauvegarde et de synchroniser tous les journaux. Cet appel ne revient pas tant que l'opération de synchronisation n'est pas terminée. Cette commande garantit que tous les messages de journal écrits avant son appel sont stockés en toute sécurité sur le disque au moment de son retour.

--syncdisponible depuis v228:

journalctl a obtenu un nouveau commutateur "--sync" qui demande au démon de journal d'écrire tous les messages de journalisation non écrits sur le disque et de synchroniser les fichiers, avant de revenir.

2. Il s'avère que journald (le démon de journalisation de systemd) ne vide pas du tout périodiquement les journaux sur le disque. Cela signifie que vos journaux sont toujours menacés à tout moment.

man journald.conf(5) dit:

SyncIntervalSec =

Délai avant la synchronisation des fichiers journaux sur le disque. Après la synchronisation, les fichiers journaux sont placés dans l'état HORS LIGNE. Notez que la synchronisation est effectuée sans condition immédiatement après l'enregistrement d'un message de journal de priorité CRIT, ALERT ou EMERG. Ce paramètre ne s'applique donc qu'aux messages des niveaux ERR, WARNING, NOTICE, INFO, DEBUG. Le délai d'expiration par défaut est de 5 minutes.

SyncIntervalSec=disponible depuis v199:

journald videra désormais explicitement les fichiers journaux sur le disque au plus tard 5 minutes après chaque écriture. Le fichier sera également marqué hors ligne jusqu'à la prochaine écriture. Cela devrait augmenter la fiabilité en cas de crash. Le délai de synchronisation peut être configuré via SyncIntervalSec = dans journald.conf.

Voir également:

journald: envoie SIGTERM / SIGINT avec une faible priorité

Assurons-nous de traiter toutes les données du journal en file d'attente avant de quitter, afin de ne pas perdre inutilement les messages lors de l'arrêt.