J'ai remarqué que mon /var/log/boot.log
fichier a la date 2016-04-22, la dernière fois que j'ai démarré en 15.10. Où se trouvent les boot.log
fichiers Xenial ?
J'ai remarqué que mon /var/log/boot.log
fichier a la date 2016-04-22, la dernière fois que j'ai démarré en 15.10. Où se trouvent les boot.log
fichiers Xenial ?
Réponses:
journalctl
Puisqu'il journald
contient tous les journaux, vous pouvez utiliser la journalctl
commande avec des filtres appropriés. Dans le cas de boot.log
, qui contenait autrefois des messages du système init, vous pouvez faire:
journalctl -b0 SYSLOG_PID=1
-b0
affiche les messages du démarrage actuel, -b1
du démarrage précédent, etc. Sans l' -b
option, journalctl
affichera les messages depuis le début du journal.SYSLOG_PID
filtre les messages du PID 1, alias init.Ou:
journalctl -b0 --system _COMM=systemd
_COMM=systemd
recherche les messages de la systemd
commande. Puisque systemd
c'est init, c'est celui qui nous intéresse.--system
filtre les messages du journal système au lieu des journaux de session 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 rediriger vers less
.
Ubuntu, par défaut, n'active pas les journaux journaliers persistants. Grâce au commentaire de @Auspex , vous devez effectuer l'une des actions suivantes :
Modifier /etc/systemd/journald.conf
pour inclure:
Storage=persistent
Créez un /var/log/journal
répertoire manuellement:
mkdir /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
En relation:
journalctl -bX
est inutile pour cela, id ne contient pas de messages qui apparaissent vraiment à l'écran lors du démarrage, seul boot.log le fait et cela ne fonctionne que parfois le 16.04, le seul moyen est de prendre une photo ou de l'écrire. J'ai le même problème.
Je parcourais quelques rapports de bogues et j'ai remarqué dans celui-ci: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771 que Plymouth écrit réellement dans boot.log.
Si vous regardez https://launchpadlibrarian.net/257898272/plymouth-debug.log et recherchez dans votre navigateur «boot.log», 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 composants internes de Plymouth, mais comme il est responsable de l'écran de démarrage qui s'affiche 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 un écran de démarrage s'affiche avant l'écran de connexion, la sortie du processus de démarrage est redirigée vers le fichier boot.log.
GRUB_CMDLINE_LINUX_DEFAULT=""
dans /etc/default/grub
de boot.log
n'est pas écrite. Lors de l'utilisation GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
de ce qui boot.log
est à nouveau écrit. J'utilise Ubuntu 19.04.
Dans Ubuntu 16.04, le boot.log
fichier se trouve toujours dans le /var/log
dossier comme vous pouvez le voir ici . Le fichier journal de démarrage date d'aujourd'hui (29/04/2016). 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 vers Ubuntu 16.04 LTS.
Vous pouvez également examiner le comportement de démarrage général à partir du kern.log
fichier complet . Une autre alternative possible serait de configurer manuellement le démon syslog pour générer le fichier journal de démarrage et voici un tutoriel comment faire exactement cela: Comment afficher et configurer les journaux Linux
Information additionnelle :
J'ai étudié le comportement de journalisation du démarrage sur deux machines différentes. Sur un ordinateur avec un BIOS basé sur UEFI, le boot.log
fichier existe - mais sur un ordinateur avec un BIOS basé sur l'héritage, il semble qu'il n'existe pas du tout. Donc, si le système est installé en mode BIOS hérité (MBR / msdos), cela pourrait expliquer pourquoi votre boot.log
fichier est daté du 22/04/2016, c'est un reste d'Ubuntu 15.10.
Informations mises à jour 2016-05-02:
J'ai continué à enquêter sur le comportement du fichier journal de démarrage et j'ai observé que le boot.log
fichier existe toujours sur la machine basée sur UEFI, mais depuis quelques jours, le fichier est vide. Une autre alternative, j'ai essayé de voir ce qui se passe pendant le processus de démarrage, était d'installer BootChart , mais bootchart.png
n'existait pas dans le /var/log
dossier comme prévu après le redémarrage du système ... il n'y avait qu'un /var/log/bootchart
dossier vide qui ne contenait pas non plus le bootchart.png
fichier attendu .
Informations mises à jour 2016-05-04:
Aujourd'hui, le boot.log
fichier semble à nouveau avoir une "fonctionnalité", il est rempli d'informations partielles du processus de démarrage. Il semble que ce soit un comportement qui change aléatoirement et qui, 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 boot.log
comportement des fichiers dans Ubuntu 16.04: vous ne devriez plus vous inquiéter /var/log/boot.log
et vous y habituer journalctl
.
boot.log
fichier n'est pas à son emplacement habituel.
systemd-analyze blame
et / ousystemd-analyze critical-chain
. Je trouve cela plus facile que de creuser à travers des fichiers journaux pour trouver ce qui cause un problème.