Zauważyłem, że mój /var/log/boot.log
plik ma datę 2016-04-22, ostatni raz uruchomiłem w 15.10. Gdzie znajdują się boot.log
pliki Xenial ?
Zauważyłem, że mój /var/log/boot.log
plik ma datę 2016-04-22, ostatni raz uruchomiłem w 15.10. Gdzie znajdują się boot.log
pliki Xenial ?
Odpowiedzi:
journalctl
Ponieważ journald
zawiera wszystkie dzienniki, możesz użyć journalctl
polecenia z odpowiednimi filtrami. W przypadku boot.log
, który zawierał wiadomości z systemu init, możesz:
journalctl -b0 SYSLOG_PID=1
-b0
pokazuje wiadomości z bieżącego rozruchu, -b1
z poprzedniego rozruchu i tak dalej. Bez -b
opcji journalctl
wyświetli komunikaty od początku dziennika.SYSLOG_PID
filtruje wiadomości z PID 1, czyli init.Lub:
journalctl -b0 --system _COMM=systemd
_COMM=systemd
szuka wiadomości z systemd
polecenia. Ponieważ systemd
jest init, tym się interesujemy.--system
filtruje wiadomości z dziennika systemowego zamiast dzienników sesji użytkownika.Przykład:
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
domyślnie otwiera dzienniki w pagerze, więc nie trzeba przesyłać do potoku less
.
Ubuntu domyślnie nie włącza trwałych dzienników dziennika. Dzięki komentarzowi @Auspex musisz wykonać jedną z następujących czynności:
Edytuj, /etc/systemd/journald.conf
aby uwzględnić:
Storage=persistent
Utwórz /var/log/journal
katalog ręcznie:
mkdir /var/log/journal
systemd-tmpfiles --create --prefix /var/log/journal
systemctl restart systemd-journald
Związane z:
journalctl -bX
jest do tego bezużyteczny, id nie zawiera komunikatów, które naprawdę pojawiają się na ekranie podczas uruchamiania, działa tylko boot.log i działa tylko czasami 16.04, jedynym sposobem jest zrobienie zdjęcia lub zapisanie go. Mam ten sam problem.
Przeglądałem niektóre raporty o błędach i zauważyłem w tym: https://bugs.launchpad.net/ubuntu/+source/ubuntu-gnome-default-settings/+bug/1536771, że Plymouth faktycznie pisze na boot.log.
Jeśli spojrzysz na https://launchpadlibrarian.net/257898272/plymouth-debug.log i poszukasz w przeglądarce hasła „boot.log”, otrzymasz następujące wiersze:
[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'
Nie rozumiem, jak działają elementy wewnętrzne Plymouth, ale ponieważ jest odpowiedzialny za ekran powitalny, który pojawia się przed ekranem logowania, mogę jedynie założyć, że jeśli nie ma ekranu powitalnego (czarny ekran) przed przejściem do ekranu logowania , plik nie jest modyfikowany. Jeśli ekran powitalny wyświetla się przed ekranem logowania, dane wyjściowe procesu rozruchu są przekierowywane do pliku boot.log.
GRUB_CMDLINE_LINUX_DEFAULT=""
w /etc/default/grub
nie boot.log
jest napisane. Przy użyciu GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
niż boot.log
jest ponownie napisane. Używam Ubuntu 19.04.
W Ubuntu 16.04 boot.log
plik nadal znajduje się w /var/log
folderze, jak widać tutaj . Plik dziennika rozruchu pochodzi z dzisiaj (2016-04-29). Być może coś poszło nie tak podczas instalacji Ubuntu 16.04 lub aktualizacji systemu operacyjnego z Ubuntu 15.10 do Ubuntu 16.04 LTS.
Alternatywnie możesz sprawdzić ogólne zachowanie podczas uruchamiania z kern.log
pliku kompleksowego . Inną możliwą alternatywą byłoby ręczne skonfigurowanie demona syslog w celu wygenerowania pliku dziennika rozruchu. Oto samouczek, jak to zrobić: Jak wyświetlić i skonfigurować dzienniki systemu Linux
Dodatkowe informacje :
Zbadałem zachowanie rejestrowania rozruchu na dwóch różnych komputerach. Na komputerze z systemem BIOS opartym na UEFI boot.log
plik istnieje - ale na komputerze ze starszym systemem BIOS wydaje się, że w ogóle nie istnieje. Więc jeśli system jest zainstalowany w starszym trybie BIOS (MBR / msdos), może to być wyjaśnienie, dlaczego twój boot.log
plik jest datowany od 22.04.2016, to pozostałość po Ubuntu 15.10.
Zaktualizowane informacje 2016-05-02:
Kontynuowałem badanie zachowania pliku dziennika rozruchu i zauważyłem, że boot.log
plik nadal istnieje na komputerze z interfejsem UEFI, ale od kilku dni plik jest pusty. Inną alternatywą, którą próbowałem zobaczyć, co dzieje się podczas procesu rozruchu, była instalacja BootChart , ale bootchart.png
nie istniała w /var/log
folderze, jak oczekiwano po ponownym uruchomieniu systemu ... był tylko pusty /var/log/bootchart
folder, który również nie zawierał oczekiwanego bootchart.png
pliku.
Zaktualizowane informacje 2016-05-04:
Dziś boot.log
plik wydaje się znów mieć „funkcjonalność”, jest wypełniony częściowymi informacjami z procesu uruchamiania. Wygląda to na losowo zmieniające się zachowanie, które moim zdaniem nie może zostać rozwiązane tutaj na Ask Ubuntu - dlatego powinieneś rozważyć zgłoszenie błędu na Launchpad, aby rozwiązać ten problem!
Wniosek - po tygodniu badania boot.log
zachowania plików w Ubuntu 16.04: Nie powinieneś się już martwić /var/log/boot.log
i po prostu przyzwyczaj się journalctl
.
boot.log
plik nie znajduje się w zwykłej lokalizacji.
systemd-analyze blame
i / lubsystemd-analyze critical-chain
. Uważam, że jest to łatwiejsze niż kopanie plików dziennika w celu znalezienia przyczyny problemu.