web-dev-qa-db-fra.com

Plus de journalisation au démarrage depuis 16.04?

J'ai remarqué que mon fichier /var/log/boot.log porte la date du 2016-04-22, la dernière fois que j'ai démarré dans 15.10. Où se trouvent les fichiers Xenial boot.log?

boot16.04loglogging
23
jasmines

Utilisez journalctl

Comme journald contient tous les journaux, vous pouvez utiliser la commande journalctl avec des filtres appropriés. Dans le cas de boot.log, qui contenait des messages du système init, vous pouvez effectuer les opérations suivantes:

journalctl -b0 SYSLOG_PID=1
  • -b0 affiche les messages du démarrage actuel, -b1 du démarrage précédent, etc. Sans l'option -b, journalctl affichera les messages depuis le début du journal.
  • SYSLOG_PID filtre les messages du PID 1, autrement dit init.

Ou:

journalctl -b0 --system _COMM=systemd
  • _COMM=systemd recherche les messages de la commande systemd. Puisque systemd est init, c’est celui qui nous intéresse.
  • --system filtre les messages du journal système au lieu des journaux de session de l'utilisateur.

Exemple:

muru@muru-vm:~$ journalctl -b0 SYSLOG_PID=1
Apr 30 12:29:18 muru-vm systemd[1]: systemd 229 running in system mode. (+PA
Apr 30 12:29:18 muru-vm systemd[1]: Detected virtualization qemu.
Apr 30 12:29:18 muru-vm systemd[1]: Detected architecture x86-64.
Apr 30 12:29:18 muru-vm systemd[1]: Set hostname to <muru-vm>.
Apr 30 12:29:18 muru-vm systemd[1]: Initializing machine ID from random gene
Apr 30 12:29:18 muru-vm systemd[1]: Installed transient /etc/machine-id file
Apr 30 12:29:18 muru-vm systemd[1]: Set up automount Arbitrary Executable Fi
Apr 30 12:29:18 muru-vm systemd[1]: Listening on fsck to fsckd communication
Apr 30 12:29:18 muru-vm systemd[1]: Reached target User and Group Name Looku
Apr 30 12:29:18 muru-vm systemd[1]: Listening on udev Kernel Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Started Forward Password Requests to Wal
Apr 30 12:29:18 muru-vm systemd[1]: Listening on /dev/initctl Compatibility 
Apr 30 12:29:18 muru-vm systemd[1]: Listening on Journal Socket.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice User and Session Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Created slice System Slice.
Apr 30 12:29:18 muru-vm systemd[1]: Starting Braille Device Support...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting POSIX Message Queue File System
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Debug File System...
Apr 30 12:29:18 muru-vm systemd[1]: Mounting Huge Pages File System...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Load Kernel Modules...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Uncomplicated firewall...
Apr 30 12:29:18 muru-vm systemd[1]: Starting Create list of required static 
lines 1-23

journalctl ouvre les journaux dans un pager par défaut, vous n’avez donc pas besoin de diriger vers less.

Enregistrement persistant

Ubuntu, par défaut, n'active pas les journaux persistants. Grâce à le commentaire de @Auspex , vous devez effectuer l'une des actions suivantes:

  1. Éditez /etc/systemd/journald.conf pour inclure:

    Storage=persistent

  2. Créez un répertoire /var/log/journal manuellement:

    mkdir /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald

En relation:

31
muru

Je passais en revue des rapports de bugs et j'ai remarqué dans celui-ci: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 que Plymouth est en train d'écrire sur boot.log.

Si vous regardez https://launchpadlibrarian.net/257898272/plymouth-debug.log et recherchez "boot.log" dans votre navigateur, vous obtenez les lignes suivantes:

[main.c:821] on_system_initialized:system now initialized, opening log 
[main.c:742] get_log_file_for_state:returning log file '/var/log/boot.log'
[main.c:805] prepare_logging:opening log '/var/log/boot.log'

Je ne comprends pas comment fonctionnent les éléments internes de Plymouth, mais comme il est responsable de l'écran de démarrage qui apparaît avant l'écran de connexion, je ne peux que supposer que s'il n'y a pas d'écran de démarrage (écran noir) avant d'accéder à l'écran de connexion , le fichier n'est pas modifié. Si vous disposez d'un écran de démarrage affiché avant l'écran de connexion, la sortie du processus de démarrage est redirigée vers le fichier boot.log.

3
octoquad

Dans Ubuntu 16.04, le fichier boot.log se trouve toujours dans le dossier /var/log comme vous pouvez le voir ici . Le fichier journal de démarrage est celui d'aujourd'hui (2016-04-29). Peut-être que quelque chose s'est mal passé lorsque vous avez installé Ubuntu 16.04 ou que vous avez mis à niveau le système d'exploitation d'Ubuntu 15.10 à Ubuntu 16.04 LTS.

Vous pouvez également examiner le comportement de démarrage général à partir du fichier complet kern.log. Une autre alternative possible serait de configurer manuellement le démon syslog pour générer le fichier journal de démarrage. un tutoriel comment faire exactement ceci: Comment afficher et configurer les journaux Linux

Information additionnelle :

J'ai étudié le comportement de journalisation de démarrage sur deux ordinateurs différents. Sur un ordinateur doté d'un BIOS basé sur UEFI, le fichier boot.log existe - mais sur un ordinateur doté d'un BIOS hérité, il semble ne pas exister du tout. Donc, si le système est installé en mode BIOS (MBR/MSDOS), cela pourrait expliquer pourquoi votre fichier boot.log est daté du 2016-04-22, il s'agit d'un reliquat d'Ubuntu 15.10.

Informations mises à jour 2016-05-02:

J'ai continué à étudier le comportement du fichier de journalisation de démarrage et ai observé que le fichier boot.log existe toujours sur la machine UEFI, mais que depuis quelques jours, le fichier est vide. Une autre alternative que j'ai essayé de voir pendant le processus de démarrage consistait à installer BootChart , mais bootchart.png n'existait pas dans le dossier /var/log comme prévu après le redémarrage du système ... il n'y avait qu'un dossier /var/log/bootchart vide. qui ne contenait pas non plus le fichier bootchart.png attendu.

Information mise à jour le 2016-05-04:

Aujourd'hui, le fichier boot.log semblait avoir à nouveau une "fonctionnalité", il est rempli avec des informations partielles provenant du processus de démarrage. Cela semble être un comportement changeant de manière aléatoire, que je pense ne peut pas être résolu ici sur Ask Ubuntu - vous devriez donc envisager de déposer un rapport de bogue sur Launchpad pour résoudre ce problème!

Conclusion - après une semaine d'enquête sur le comportement du fichier boot.log dans Ubuntu 16.04: Ne vous inquiétez plus pour le /var/log/boot.log et habituez-vous plutôt à journalctl .

2
cl-netbox