Nie musisz już rejestrować rozruchu od 16.04?


23

Zauważyłem, że mój /var/log/boot.logplik ma datę 2016-04-22, ostatni raz uruchomiłem w 15.10. Gdzie znajdują się boot.logpliki Xenial ?


Prawdziwe pytanie nie polega na rejestrowaniu, ale na sprawdzeniu, co spowalnia rozruch. Teraz używasz systemd-analyze blamei / lub systemd-analyze critical-chain . Uważam, że jest to łatwiejsze niż kopanie plików dziennika w celu znalezienia przyczyny problemu.
oldfred

więc nikt z was nie może powiedzieć, dlaczego boot.log odbywa się w dniu 22.04.2016 ...? NAPRAWDĘ?
jaśmin

1
@jasmines: Niestety nie możemy powiedzieć, dlaczego tak się dzieje ... nie jesteśmy programistami ... Zaktualizowałem swoją odpowiedź kilkoma nowymi informacjami od dziś ... powinieneś rozważyć zgłoszenie błędu na Launchpad. :)
cl-netbox

2
Journalctl nie pokazuje tego, co widzę podczas powitania, i potrzebuję tego
jaśmin

1
ten ładnie wyglądający dziennik z „[FAILED]” na czerwono, czy udało ci się go odzyskać? mój plik pochodzi z 2017 roku ...
Aquarius Power

Odpowiedzi:


33

Posługiwać się journalctl

Ponieważ journaldzawiera wszystkie dzienniki, możesz użyć journalctlpolecenia z odpowiednimi filtrami. W przypadku boot.log, który zawierał wiadomości z systemu init, możesz:

journalctl -b0 SYSLOG_PID=1
  • -b0pokazuje wiadomości z bieżącego rozruchu, -b1z poprzedniego rozruchu i tak dalej. Bez -bopcji journalctlwyświetli komunikaty od początku dziennika.
  • SYSLOG_PID filtruje wiadomości z PID 1, czyli init.

Lub:

journalctl -b0 --system _COMM=systemd
  • _COMM=systemdszuka wiadomości z systemdpolecenia. Ponieważ systemdjest 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

journalctldomyślnie otwiera dzienniki w pagerze, więc nie trzeba przesyłać do potoku less.


Trwałe logowanie

Ubuntu domyślnie nie włącza trwałych dzienników dziennika. Dzięki komentarzowi @Auspex musisz wykonać jedną z następujących czynności:

  1. Edytuj, /etc/systemd/journald.confaby uwzględnić:

    Storage=persistent
    
  2. Utwórz /var/log/journalkatalog ręcznie:

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

Związane z:


1
Journalctl nie pokazuje tego, co widzę podczas powitania, i potrzebuję tego
jaśmin

1
Widzę to, co było wcześniej logowane w boot.log, w tym formacie: [OK] Uruchomiłem demona Self Monitoring and Reporting Technology (SMART). Montowanie arbitralnych formatów plików wykonywalnych System plików ... [OK] Uruchomiono usługę logowania. Uruchamianie LSB: Uruchom demona NTP ... [OK] Uruchomiłem Avahi mDNS / DNS-SD Stack. [OK] Rozpocznij Udostępnij zdalne drukarki CUPS lokalnie. [OK] Uruchomił Modem Manager. [OK] Uruchomiono Network Managera. Uruchamianie Menedżera sieci Poczekaj online ... [OK] Osiągnięto sieć docelową. [OK] Uruchomiono usługę kont. i tak dalej ...
jaśmin

1
Zachowaj miły ton i słowa. Jest miła polityka. Podążaj za tym.
Seth

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

1
Jak już wspomniano w jaśminach, komunikaty rozruchowe zaczynające się od [OK] ... to jest w boot.log, ale w dzienniku jest trochę inaczej, nawet przy użyciu flag takich jak -b0 SYSLOG_PID = 1 lub -b1 dla poprzedniego rozruchu, nie wszystko było tam szczególnie napotkałem błędy i nie mogłem znaleźć nigdzie w logach. Większość komunikatów tam jest, nie wiem jak odtworzyć ten problem, więc nie mogę pomóc, ale to był błąd jądra i nie można go było znaleźć, problem zniknął teraz, ale wciąż nie widzę powodu, dla którego boot wiadomości nie są rejestrowane dokładnie tak, jak są wyświetlane na ekranie.
Mike

3

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.


Niestety, mam plusk, ale nie boot.log ...
Jasmines

1
Potwierdzam, że podczas konfiguracji GRUB_CMDLINE_LINUX_DEFAULT=""w /etc/default/grubnie boot.logjest napisane. Przy użyciu GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"niż boot.logjest ponownie napisane. Używam Ubuntu 19.04.
adrhc

2

W Ubuntu 16.04 boot.logplik nadal znajduje się w /var/logfolderze, 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.logpliku 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.logplik 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.logplik 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.logplik 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.pngnie istniała w /var/logfolderze, jak oczekiwano po ponownym uruchomieniu systemu ... był tylko pusty /var/log/bootchartfolder, który również nie zawierał oczekiwanego bootchart.pngpliku.

Zaktualizowane informacje 2016-05-04:

Dziś boot.logplik 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.logzachowania plików w Ubuntu 16.04: Nie powinieneś się już martwić /var/log/boot.logi po prostu przyzwyczaj się journalctl.


nie myśl, że coś poszło nie tak, w każdym razie chciałbym zaakceptować twoją odpowiedź, jeśli możesz dodać sugestie dotyczące rozwiązania mojego problemu ...
jaśmin

Próbowałem ręcznie skonfigurować demona syslog, aby wygenerował plik dziennika rozruchu zgodnie z samouczkiem. Dodałem # Zapisz komunikaty rozruchowe również do boot.log local7. * /Var/log/boot.log do mojego pliku /etc/rsyslog.d/50-default.conf nie ma szczęścia, /var/log/boot.log jest nadal 22.04.2016
Jasmines

Podczas mojej nowej instalacji Ubuntu 16.04 odkryłem również, że boot.logplik nie znajduje się w zwykłej lokalizacji.

@ParanoidPanda: Na obu wymienionych komputerach wykonałem czystą / świeżą instalację (nie aktualizacji) Ubuntu 16.04 LTS - wygląda na to, że poprzedni sposób logowania do rozruchu nie jest już odpowiednio obsługiwany. :)
cl-netbox

1
Journalctl nie pokazuje tego, co widzę podczas powitania, i potrzebuję tego
jaśmin
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.