Как найти причину перезагрузки Linux?

Часто случается, что система Linux перезагружается незапланировано или по неизвестным очевидным причинам. Поиск и устранение основной причины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев.

Есть несколько способов узнать, что вызвало перезагрузку. В этой статье мы собираемся обсудить эти способы и то, как вы можете использовать доступные утилиты и журналы в системе Linux для устранения неполадок в таких сценариях.

Проверьте время перезагрузки

Проверить, когда произошла перезагрузка системы, можно командой who и last

$ who -b системная загрузка 13.02.2021 20:51 $ last -x | голова | tac abhishek pts/0 192.168.1.16 Сб 13 фев 19:53 – 19:55 (00:02) reboot system boot 3.10.0-1160.11.1 Сб 13 фев 19:55 – 20:54 (00:58) runlevel ( до 3 ур.) 3.10.0-1160.11.1 Сб 13 Фев 19:55 – 20:04 (00:08) abhishek pts/0 192.168.1.16 Сб 13 Фев 19:56 – 20:04 (00:07) перезагрузка системы boot 3.10.0-1160.11.1 Сб 13 фев 20:04 – 20:54 (00:49) runlevel (до 3 уровня) 3.10.0-1160.11.1 Сб 13 фев 20:04 – 20:51 (00:46) ) abhishek pts/0 192.168.1.16 Сб 13 фев 20:04 – 20:50 (00:46) reboot system boot 3.10.0-1160.11.1 Сб 13 фев 20:51 – 20:54 (00:03) уровень запуска ( до 3 ур.) 3.10.0-1160.11.1 Сб 13 фев 20:51 – 20:54 (00:02) abhishek pts/0 192.168.1.16 Сб 13 фев 20:51 еще залогинился $

Проверьте системные сообщения

Вы можете дополнительно сопоставить перезагрузку, которую хотите диагностировать, с системными сообщениями.

Для систем CentOS/RHEL вы найдете журналы в /var/log/messages, а для систем Ubuntu/Debian — в /var/log/syslog. Вы можете просто использовать команду tail или свой любимый текстовый редактор, чтобы отфильтровать или найти определенные данные.

Как видно из приведенных ниже журналов, такие записи предполагают завершение работы/перезагрузку, инициированные администратором или пользователем root. Эти сообщения могут различаться в зависимости от типа ОС и способа перезагрузки/выключения, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя они могут быть недостаточно явными, чтобы каждый раз точно определять причину.

13 фев 19:56:20 centos7vm хронид[637]: Источник 72.30.35.89 заменен на 142.147.92.5 13 февраля 20:00:40 centos7vm chronyd[637]: Выбранный источник 162.159.200.123 13 февраля 20:01:01 centos7vm systemd: Создан фрагмент Пользовательский фрагмент корня. 13 февраля, 20:01:01 centos7vm systemd: запущен сеанс 2 пользователя root. 13 февраля, 20:04:09 centos7vm systemd-logind: Система выключается. 13 февраля, 20:04:09 centos7vm systemd: закрыт сокет демона опроса LVM2. 13 февраля, 20:04:09 centos7vm systemd: остановлена ​​целевая многопользовательская система.

Одна из таких команд, которую вы можете использовать для фильтрации системных журналов, приведена ниже:

sudo grep -iv ‘: запуск\|ядро: .*: Кнопка питания\|отслеживание системных кнопок\|Остановка очистки\|Запущено ядро ​​восстановления после сбоя’ \ /var/log/messages /var/log/syslog /var/log /apcupsd* \ | grep -iw ‘восстановить[a-z]*\|мощность[a-z]*\|закрыть[a-z ]*вниз\|rsyslogd\|ups’

Захваченные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к отключению/сбою системы.

Проверить журналы аудита

Для систем с auditd это отличное место для проверки различных событий с помощью инструмента ausearch. Используйте приведенную ниже команду, чтобы проверить последние две записи из журналов аудита.

$ sudo ausearch -i -m system_boot,system_shutdown | хвост -4

Это сообщит о двух последних отключениях или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN, за которым следует SYSTEM_BOOT, все должно быть хорошо. Но если он сообщает о двух строках SYSTEM_BOOT подряд или только об одной строке SYSTEM_BOOT, то, скорее всего, система не завершила работу надлежащим образом. Нормальный вывод должен выглядеть примерно так:

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4 —- type=SYSTEM_SHUTDOWN msg=audit (суббота, 13 февраля 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=? адрес=? терминал =? res=success’ —- type=SYSTEM_BOOT msg=audit (суббота, 13 февраля 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=? адрес=? терминал =? res=успех’ $

В приведенном ниже выводе перечислены два последовательных сообщения SYSTEM_BOOT, которые могут указывать на некорректное завершение работы, хотя их необходимо сопоставить с системными журналами.

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4 —- type=SYSTEM_BOOT msg=audit (суббота, 13 февраля 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=? адрес=? терминал =? res=success’ —- type=SYSTEM_BOOT msg=audit (суббота, 13 февраля 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=? адрес=? терминал =? res=успех’ $

Анализ системного журнала

У вас должен быть постоянный системный журнал, чтобы вести постоянный журнал на диске, иначе журналы не сохранятся при перезагрузке. Для этого вы можете либо внести изменения в /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 —Вед 2020-11-18 23:20:08 IST -13 F2EE8A61BF4C4F67A12E012855D8B1C3 Ср 2020-11-18 23:20:17 IST-WED 2020-11-18 23:23:01 IST -12 1277D19A959F4C333BAING94A118C58.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118.118C58.118C58.118C58.118.118. 10:32:44 IST—Пт 11.12.2020 10:43:39 IST -11 eb4ff97f112445888a5946d1155de1b8 Пт 11.12.2020 10:43:55 IST—Пт 11.12.2020 10:48:18 IST2bffdf039bf434effd3f Пт 2020-12-11 19:04:30 IST—Пт 2020-12-11 19:31:01 IST -9 2acf08368667423c89086579f98efd82 Вт 2020-12-15 17:36:52 IST—Вт 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 Пн 2020-12-28 16:54:11 IST—Пн 28-12-2020 22:54:22 IST -5 a2e638dc292a4db2b0a59dd44212 Tu 29 17:02:16 IST—Вт 29-12-2020 19:39:38 IST-4 f6c738df872a48d48daee1962727cca5 Ср 30-12-2020 19:09:30 IST—Ср 30-12-2020 19:20:23 IST-3 C876E60EA371460B94E247B40270B18F THU 2020-12-31 14:36:07 IST-THU 2020-12-31 15:45:36 IST -2 A23C70804EC243F7868C18737F4B7E5551-02-02-13-131313011111111111111111111111111111111111111111111111111111111111111111111111111111111111130111111111301111130111302:302-02-13136868C18737f4B7 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 $

Как видите, этого списка хватает на несколько сапог. Для дальнейшего анализа конкретной перезагрузки используйте:

$журналctl -b {число} -n

Здесь {num} будет индексом, указанным в команде journalctl –list-boots в первом столбце.

$ journalctl -b -1 -n — Журналы начинаются в среду 18-11-2020 23:09:05 IST, заканчиваются в субботу 13-02-2021 21:13:39 IST. — 13 февраля 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: успешно. 13 фев 20:23:18 ubuntumate20vm systemd[1]: Остановлен мониторинг зеркал LVM2, моментальных снимков и т. д. с помощью dmeventd или опроса хода выполнения. 13 фев 20:23:18 ubuntumate20vm systemd[1]: Достигнуто целевое отключение. 13 фев 20:23:18 ubuntumate20vm systemd[1]: Достигнута цель Final Step. 13 фев 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: успешно. 13 фев 20:23:18 ubuntumate20vm systemd[1]: завершено отключение питания. 13 фев 20:23:18 ubuntumate20vm systemd[1]: Достигнуто целевое отключение питания. 13 фев 20:23:18 ubuntumate20vm systemd[1]: Выключение. 13 февраля 20:23:18 ubuntumate20vm systemd-shutdown[1]: Синхронизация файловых систем и блочных устройств. 13 февраля 20:23:18 ubuntumate20vm systemd-journald[304]: Журнал остановлен $

Вы можете просмотреть сообщения, зарегистрированные в журнале, в приведенном выше выводе и отследить аномалии, если таковые имеются.

Вывод

Не всегда возможно точно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Таким образом, всегда полезно знать команды и журналы, которые фиксируют системные события и могут сократить время, необходимое для поиска основной причины.

Приведенные выше примеры являются отправной точкой для начала устранения неполадок. Используя комбинацию таких инструментов и журналов, вы можете быть уверены, что знаете, что произошло и как ваша система перезагрузилась.

Затем узнайте о некоторых легковесных программах мониторинга для Linux.