Se întâmplă adesea să descoperim că un sistem Linux a repornit într-un mod neplanificat sau din motive aparente necunoscute. Găsirea și rezolvarea cauzei rădăcină poate ajuta la prevenirea reapariției unor astfel de probleme și la evitarea perioadelor de nefuncționare neplanificate.
Există mai multe moduri prin care putem afla ce a declanșat o repornire. În acest articol, vom discuta despre aceste moduri și despre cum puteți utiliza utilitățile și jurnalele disponibile într-un sistem Linux pentru a depana astfel de scenarii.
Cuprins
Inspectați timpul de repornire
Puteți verifica când a avut loc repornirea sistemului cu cine și ultimele comenzi
$ 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 $
Verificați mesajele de sistem
Puteți corela în continuare repornirea pe care doriți să o diagnosticați cu mesajele de sistem.
Pentru sistemele CentOS/RHEL, veți găsi jurnalele la /var/log/messages, în timp ce pentru sistemele Ubuntu/Debian, sunt înregistrate la /var/log/syslog. Puteți utiliza pur și simplu comanda tail sau editorul de text preferat pentru a filtra sau a găsi date specifice.
După cum se poate deduce din jurnalele de mai jos, astfel de intrări sugerează o oprire/repornire inițiată de un administrator sau utilizator root. Aceste mesaje pot varia în funcție de tipul de sistem de operare și de modul în care este declanșată repornirea/oprirea, dar veți găsi întotdeauna informații utile uitându-vă la jurnalele de sistem, deși este posibil să nu fie suficient de explicit pentru a identifica cauza de fiecare dată.
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.
O astfel de comandă pe care o puteți folosi pentru a filtra jurnalele de sistem este prezentată mai jos:
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'
Este posibil ca evenimentele capturate să nu fie întotdeauna specifice. Urmăriți întotdeauna evenimentele care dau semne de avertismente sau erori care pot duce la oprirea sau blocarea sistemului.
Verificați jurnalele de audit
Pentru sistemele cu auditd, este un loc minunat pentru a verifica diferite evenimente folosind instrumentul de căutare. Utilizați comanda de mai jos pentru a verifica ultimele două intrări din jurnalele de audit.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Aceasta va raporta cele mai recente două opriri sau reporniri. Dacă acest lucru raportează un SYSTEM_SHUTDOWN urmat de un SYSTEM_BOOT, totul ar trebui să fie bine. Dar, dacă raportează două linii SYSTEM_BOOT la rând sau doar o singură linie SYSTEM_BOOT, atunci cel mai probabil, sistemul nu s-a oprit cu grație. O ieșire normală ar trebui să fie ceva ca mai jos:
$ 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' $
Ieșirea de mai jos listează două mesaje SYSTEM_BOOT consecutive, care pot indica o închidere incorectă, deși trebuie să fie corelate cu jurnalele de sistem.
$ 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ți jurnalul de sistem
Ar trebui să aveți un systemd-journal persistent pentru a păstra un jurnal persistent pe disc, altfel jurnalele nu vor persista la repornire. Pentru aceasta, puteți fie să faceți modificările în /etc/systemd/journald.conf, fie să creați singur directorul cu comenzile de mai jos:
$ sudo mkdir /var/log/journal $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null $ sudo systemctl -s SIGUSR1 kill systemd-journald
Odată terminat, puteți reporni opțional sistemul pentru a captura mai mult de o intrare de repornire în jurnal, deși nu este necesar.
Utilizați comanda de mai jos pentru a lista boot-urile înregistrate din jurnal:
$ journalctl --list-boots
Iată rezultatul său pe serverul meu:
$ 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 $
După cum puteți vedea, lista durează mai multe cizme. Pentru a analiza în continuare o anumită repornire, utilizați:
$ journalctl -b {num} -n
Aici {num} va fi indexul dat în comanda journalctl –list-boots în prima coloană.
$ 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 $
Puteți observa mesajele înregistrate în jurnal în rezultatul de mai sus și puteți urmări anomaliile dacă există.
Concluzie
Este posibil să nu fie întotdeauna posibilă identificarea cauzei unei reporniri Linux folosind o singură comandă sau dintr-un singur fișier jurnal. Ca atare, este întotdeauna util să cunoașteți comenzile și jurnalele care captează evenimente legate de sistem și pot scurta timpul necesar pentru a găsi cauza principală.
Exemplele de mai sus vă oferă un loc de pornire pentru a începe depanarea. Folosind o combinație de astfel de instrumente și jurnale, puteți fi sigur că știți ce s-a întâmplat și cum a repornit sistemul dvs.
Apoi, aflați câteva dintre software-urile de monitorizare a greutăților ușoare pentru Linux.