Plus de journalisation de démarrage depuis le 16.04?


23

J'ai remarqué que mon /var/log/boot.logfichier a la date 2016-04-22, la dernière fois que j'ai démarré en 15.10. Où se trouvent les boot.logfichiers Xenial ?


La vraie question n'est pas de se connecter, mais de voir ce qui ralentit le démarrage. Maintenant, vous utilisez systemd-analyze blameet / ou systemd-analyze critical-chain . Je trouve cela plus facile que de creuser à travers des fichiers journaux pour trouver ce qui cause un problème.
oldfred

donc, aucun de vous ne peut dire pourquoi boot.log a lieu le 22/04/2016 ...? VRAIMENT?
jasmin

1
@jasmines: Malheureusement, nous ne pouvons pas vous expliquer pourquoi cela se produit ... nous ne sommes pas les développeurs ... J'ai mis à jour ma réponse avec de nouvelles informations à partir d'aujourd'hui ... vous devriez envisager de déposer un rapport de bogue sur Launchpad. :)
cl-netbox

2
journalctl n'affiche pas ce que je vois dans les éclaboussures au démarrage, et j'en ai besoin
jasmines

1
ce joli journal avec "[FAILED]" en rouge, avez-vous réussi à l'obtenir à nouveau? mon fichier est de 2017 ...
Aquarius Power

Réponses:


33

Utilisation journalctl

Puisqu'il journaldcontient tous les journaux, vous pouvez utiliser la journalctlcommande 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
  • -b0affiche les messages du démarrage actuel, -b1du démarrage précédent, etc. Sans l' -boption, journalctlaffichera 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=systemdrecherche les messages de la systemdcommande. Puisque systemdc'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

journalctlouvre les journaux dans un pager par défaut, vous n'avez donc pas besoin de rediriger vers less.


Journalisation persistante

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 :

  1. Modifier /etc/systemd/journald.confpour inclure:

    Storage=persistent
    
  2. Créez un /var/log/journalrépertoire manuellement:

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

En relation:


1
journalctl n'affiche pas ce que je vois dans les éclaboussures au démarrage, et j'en ai besoin
jasmines

1
Je vois ce qui était connecté dans boot.log auparavant, ce format: [OK] Démarrez le démon SMART (Self Monitoring and Reporting Technology). Montage du système de fichiers de formats de fichiers exécutables arbitraires ... [OK] Service de connexion démarré. Démarrage de LSB: Démarrez le démon NTP ... [OK] Démarrage de la pile Avahi mDNS / DNS-SD. [OK] Démarré Rendre les imprimantes CUPS distantes disponibles localement. [OK] Lancez Modem Manager. [OK] Lancez Network Manager. Démarrage de Network Manager Attendre en ligne ... [OK] Réseau cible atteint. [OK] Démarrage du service des comptes. et ainsi de suite ...
jasmin

1
Gardez votre ton et vos mots sympas. Il y a une bonne politique. Suis le.
Seth

1
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.
Mike

1
Comme les jasmin l'ont déjà mentionné, les messages de démarrage commençant par [OK] ... ce truc est dans boot.log mais dans journalctl c'est peu différent, même lorsque vous utilisez des indicateurs comme -b0 SYSLOG_PID = 1 ou -b1 pour le démarrage précédent, tout n'était pas là, spécialement des erreurs que j'ai rencontrées et que je n'ai pu trouver nulle part dans les journaux. La plupart des messages sont là, je ne sais pas comment reproduire ce problème donc je ne peux pas aider, mais c'était une erreur avec le noyau et il n'était pas trouvé, le problème a disparu maintenant, mais je ne vois toujours pas pourquoi le démarrage les messages ne sont pas enregistrés exactement tels qu'ils apparaissent à l'écran.
Mike

3

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.


Malheureusement, j'ai les éclaboussures, mais pas boot.log ...
jasmins

1
Je confirme que lors de la configuration GRUB_CMDLINE_LINUX_DEFAULT=""dans /etc/default/grubde boot.logn'est pas écrite. Lors de l'utilisation GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"de ce qui boot.logest à nouveau écrit. J'utilise Ubuntu 19.04.
adrhc

2

Dans Ubuntu 16.04, le boot.logfichier se trouve toujours dans le /var/logdossier 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.logfichier 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.logfichier 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.logfichier 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.logfichier 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.pngn'existait pas dans le /var/logdossier comme prévu après le redémarrage du système ... il n'y avait qu'un /var/log/bootchartdossier vide qui ne contenait pas non plus le bootchart.pngfichier attendu .

Informations mises à jour 2016-05-04:

Aujourd'hui, le boot.logfichier 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.logcomportement des fichiers dans Ubuntu 16.04: vous ne devriez plus vous inquiéter /var/log/boot.loget vous y habituer journalctl.


ne pensez pas que quelque chose s'est mal passé, de toute façon j'aimerais accepter votre réponse si vous pouviez ajouter des suggestions sur la façon de résoudre mon problème ...
jasmines

J'ai essayé de configurer manuellement le démon syslog pour générer le fichier journal de démarrage après le didacticiel. J'ai également ajouté # Enregistrer les messages de démarrage dans boot.log local7. * /Var/log/boot.log à mon fichier /etc/rsyslog.d/50-default.conf pas de chance, /var/log/boot.log est toujours 22/04/2016
jasmins

Sur ma nouvelle installation d'Ubuntu 16.04, j'ai également constaté que le boot.logfichier n'est pas à son emplacement habituel.

@ParanoidPanda: Sur les deux machines mentionnées, j'ai effectué une installation propre / fraîche (pas une mise à niveau) d'Ubuntu 16.04 LTS - il semble que l'ancienne méthode de journalisation du démarrage ne soit plus correctement prise en charge. :)
cl-netbox

1
journalctl n'affiche pas ce que je vois dans les éclaboussures au démarrage, et j'en ai besoin
jasmines
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.