Често се случва да открием, че Linux система се е рестартирала по непланиран начин или поради неизвестни очевидни причини. Намирането и разрешаването на основната причина може да помогне за предотвратяване на повторната поява на такива проблеми и да избегне непланирани прекъсвания.
Има няколко начина, по които можем да разберем какво е предизвикало рестартиране. В тази статия ще обсъдим тези начини и как можете да използвате наличните помощни програми и регистрационни файлове в Linux система, за да отстраните подобни сценарии.
Съдържание
Проверете времето за рестартиране
Можете да проверите кога се е случило рестартирането на системата с командите who и 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 $
Проверете системните съобщения
Можете допълнително да свържете рестартирането, което искате да диагностицирате, със системните съобщения.
За системите CentOS/RHEL ще намерите регистрационните файлове в /var/log/messages, докато за системите Ubuntu/Debian, те се регистрират в /var/log/syslog. Можете просто да използвате командата tail или любимия си текстов редактор, за да филтрирате или намерите конкретни данни.
Както може да се заключи от регистрационните файлове по-долу, такива записи предполагат изключване/рестартиране, инициирано от администратор или root потребител. Тези съобщения могат да варират в зависимост от типа на операционната система и начина, по който се задейства рестартиране/изключване, но винаги ще намерите полезна информация, като разгледате системните регистрационни файлове, въпреки че може да не е достатъчно ясна, за да посочите причината всеки път.
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.
Една такава команда, която можете да използвате за филтриране на системни регистрационни файлове, е дадена по-долу:
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'
Заснетите събития може не винаги да са конкретни. Винаги проследявайте събития, които дават признаци на предупреждения или грешки, които могат да доведат до изключване/срив на системата.
Проверете auditd регистрационните файлове
За системи с auditd това е чудесно място за проверка на различни събития с помощта на инструмента ausearch. Използвайте командата по-долу, за да проверите последните два записа от журналите за проверка.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Това ще отчете двете последни изключвания или рестартирания. Ако това докладва SYSTEM_SHUTDOWN, последвано от SYSTEM_BOOT, всичко трябва да е наред. Но ако докладва два последователни реда SYSTEM_BOOT или само един ред SYSTEM_BOOT, най-вероятно системата не се е изключила правилно. Нормалният изход трябва да бъде нещо като по-долу:
$ 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' $
Изходът по-долу изброява две последователни съобщения SYSTEM_BOOT, които може да означават неудобно изключване, въпреки че трябва да бъдат свързани със системните регистрационни файлове.
$ 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' $
Анализирайте дневника на systemd
Трябва да имате постоянен systemd-журнал, за да поддържате постоянен журнал на диска, в противен случай регистрационните файлове няма да се запазят при рестартиране. За целта можете да направите промените в /etc/systemd/journald.conf или да създадете сами директорията с командите по-долу:
$ sudo mkdir /var/log/journal $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null $ sudo systemctl -s SIGUSR1 kill systemd-journald
След като приключите, можете по избор да рестартирате системата, за да заснемете повече от един запис за рестартиране в дневника, въпреки че не е задължително.
Използвайте командата по-долу, за да изброите записаните зареждания от дневника:
$ journalctl --list-boots
Ето изхода му на моя сървър:
$ 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 $
Както можете да видите, списъкът продължава няколко зареждания. За да анализирате допълнително конкретно рестартиране, използвайте:
$ journalctl -b {num} -n
Тук {num} ще бъде индексът, даден в командата journalctl –list-boots в първата колона.
$ 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 $
Можете да наблюдавате съобщенията, регистрирани в дневника в горния изход и да проследите аномалиите, ако има такива.
Заключение
Може да не винаги е възможно да се определи причината за рестартиране на Linux с помощта на една команда или от един лог файл. Като такова, винаги е удобно да знаете командите и регистрационните файлове, които улавят свързани със системата събития и могат да съкратят времето, необходимо за намиране на първопричината.
Горните примери ви предоставят отправна точка, за да започнете отстраняването на проблеми. Използвайки комбинация от такива инструменти и регистрационни файлове, можете да сте сигурни, че знаете какво се е случило и как системата ви се е рестартирала.
След това разберете някои от олекотените софтуери за наблюдение за Linux.