Nieplanowane restarty systemów Linux mogą być frustrujące i prowadzić do nieprzewidzianych przestojów. Kluczowe jest zidentyfikowanie pierwotnej przyczyny takich zdarzeń, aby zapobiec ich ponownemu wystąpieniu. Dogłębna analiza logów i wykorzystanie dostępnych narzędzi systemowych to fundament skutecznego rozwiązywania problemów.
W tym artykule przedstawimy metody diagnostyki nieoczekiwanych restartów, skupiając się na wykorzystaniu logów oraz narzędzi systemu Linux. Dzięki tej wiedzy będziesz w stanie efektywnie analizować i rozwiązywać tego typu sytuacje.
Ustalanie czasu ponownego uruchomienia
Aby sprawdzić, kiedy system został zrestartowany, możesz użyć poleceń `who` oraz `last`.
$ who -b system boot 2021-02-13 20:51 $ last -x | head | tac abhishek pts/0 192.168.1.16 Sat Feb 13 19:53 - 19:55 (00:02) reboot system boot 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:54 (00:58) runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:04 (00:08) abhishek pts/0 192.168.1.16 Sat Feb 13 19:56 - 20:04 (00:07) reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:54 (00:49) runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:51 (00:46) abhishek pts/0 192.168.1.16 Sat Feb 13 20:04 - 20:50 (00:46) reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:03) runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:02) abhishek pts/0 192.168.1.16 Sat Feb 13 20:51 still logged in $
Analiza komunikatów systemowych
Korelacja czasu ponownego uruchomienia z logami systemowymi to kolejny istotny krok diagnostyczny.
W systemach CentOS/RHEL dzienniki systemowe przechowywane są w pliku `/var/log/messages`, natomiast w systemach Ubuntu/Debian znajdziesz je w `/var/log/syslog`. Do przeglądania tych plików możesz użyć polecenia `tail` lub swojego ulubionego edytora tekstu, aby wyszukać interesujące cię informacje.
Analizując poniższe logi, można zauważyć, że niektóre wpisy wskazują na zamknięcie lub ponowne uruchomienie zainicjowane przez administratora lub użytkownika root. Treść komunikatów może się różnić w zależności od dystrybucji i sposobu zamykania systemu, ale dokładna analiza logów systemowych zawsze dostarczy cennych wskazówek. Należy jednak pamiętać, że nie zawsze logi wskażą jednoznaczną przyczynę restartu.
Feb 13 19:56:20 centos7vm chronyd[637]: Source 72.30.35.89 replaced with 142.147.92.5 Feb 13 20:00:40 centos7vm chronyd[637]: Selected source 162.159.200.123 Feb 13 20:01:01 centos7vm systemd: Created slice User Slice of root. Feb 13 20:01:01 centos7vm systemd: Started Session 2 of user root. Feb 13 20:04:09 centos7vm systemd-logind: System is powering down. Feb 13 20:04:09 centos7vm systemd: Closed LVM2 poll daemon socket. Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User System.
Poniższe polecenie umożliwia filtrowanie dzienników systemowych, wykluczając nieistotne wpisy i skupiając się na tych, które mogą wskazywać przyczynę restartu:
sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel' /var/log/messages /var/log/syslog /var/log/apcupsd* | grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'
Przechwycone zdarzenia nie zawsze wskazują bezpośrednią przyczynę. Należy zwracać szczególną uwagę na komunikaty ostrzegawcze i błędy, które mogły poprzedzać awarię lub nieplanowe wyłączenie.
Przeglądanie dzienników audytu
W systemach z włączonym `auditd` doskonałym źródłem informacji o zdarzeniach jest narzędzie `ausearch`. Poniższe polecenie pozwala na wyświetlenie dwóch ostatnich wpisów związanych z uruchomieniem i zamknięciem systemu:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Wynik pokaże ostatnie dwa wyłączenia lub restarty. Prawidłowa sekwencja to najpierw `SYSTEM_SHUTDOWN`, a potem `SYSTEM_BOOT`. Jeśli natomiast pojawią się dwa komunikaty `SYSTEM_BOOT` pod rząd, lub tylko jeden, może to oznaczać, że system nie zamknął się prawidłowo. Przykładowy prawidłowy wynik wygląda następująco:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' $
Z kolei poniższy przykład, w którym występują dwa komunikaty `SYSTEM_BOOT`, wskazuje na potencjalnie nagłe zamknięcie systemu. Warto ten wniosek skorelować z logami systemowymi.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4 ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' ---- type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success' $
Analiza dziennika systemd
Aby zachować logi po ponownym uruchomieniu, powinieneś ustawić trwałe przechowywanie dziennika. Możesz to osiągnąć, modyfikując plik `/etc/systemd/journald.conf` lub tworząc katalog logów za pomocą poniższych poleceń:
$ sudo mkdir /var/log/journal $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null $ sudo systemctl -s SIGUSR1 kill systemd-journald
Po wykonaniu powyższych kroków możesz opcjonalnie zrestartować system, aby mieć więcej wpisów w logach (chociaż nie jest to konieczne).
Aby wyświetlić listę zapisanych bootów z dziennika, użyj polecenia:
$ journalctl --list-boots
Oto przykładowy wynik z serwera:
$ journalctl --list-boots -15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST—Wed 2020-11-18 23:17:10 IST -14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST—Wed 2020-11-18 23:20:08 IST -13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST—Wed 2020-11-18 23:23:01 IST -12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST—Fri 2020-12-11 10:43:39 IST -11 eb4ff97f112445888a5946d1155de1b8 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST -10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST -9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST -8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 2020-12-19 00:44:52 IST -7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST—Wed 2020-12-23 23:02:44 IST -6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST—Mon 2020-12-28 22:54:22 IST -5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST—Tue 2020-12-29 19:39:38 IST -4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST—Wed 2020-12-30 19:20:23 IST -3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST—Thu 2020-12-31 15:45:36 IST -2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST—Sat 2021-02-13 20:10:44 IST -1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST—Sat 2021-02-13 20:23:18 IST 0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST—Sat 2021-02-13 21:13:15 IST $
Dzięki tej liście możesz przeanalizować konkretny restart, używając polecenia:
$ journalctl -b {num} -n
Gdzie `{num}` to numer z pierwszej kolumny z polecenia `journalctl –list-boots`. Na przykład:
$ journalctl -b -1 -n -- Logs begin at Wed 2020-11-18 23:09:05 IST, end at Sat 2021-02-13 21:13:39 IST. -- Feb 13 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Succeeded. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Shutdown. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Final Step. Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Succeeded. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finished Power-Off. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Power-Off. Feb 13 20:23:18 ubuntumate20vm systemd[1]: Shutting down. Feb 13 20:23:18 ubuntumate20vm systemd-shutdown[1]: Syncing filesystems and block devices. Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal stopped $
Analizując komunikaty z dziennika, poszukaj anomalii, które mogły spowodować nieoczekiwany restart.
Podsumowanie
Ustalenie przyczyny restartu systemu Linux często wymaga analizy wielu logów i nie zawsze jest możliwe przy użyciu jednego narzędzia. Znajomość dostępnych poleceń i plików logów, w których rejestrowane są zdarzenia systemowe, jest kluczowa dla efektywnej diagnostyki i skrócenia czasu potrzebnego na znalezienie przyczyny problemu.
Przedstawione w tym artykule metody stanowią dobry punkt wyjścia do rozwiązywania problemów związanych z nieplanowanymi restartami. Łącząc analizę różnych logów i narzędzi, zyskujesz pewność, że jesteś w stanie zidentyfikować przyczynę restartu i podjąć odpowiednie kroki, aby zapobiec jego ponownemu wystąpieniu.
W dalszej kolejności zachęcamy do zapoznania się z lekkimi narzędziami monitorującymi dla systemów Linux.
newsblog.pl