🐧 Как узнать причину перезагрузки Linux? |

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

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

Есть несколько способов узнать, что вызвало перезагрузку.

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

Содержание

Как узнать время перезагрузки
Как проверить системные сообщения
Как проверить логи auditd
Как проанализировать логи systemd
Заключение

Вы можете проверить, когда произошла перезагрузка системы, с помощью команд 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, чтобы вести постоянный журнал на диске, иначе журналы не сохранятся при перезагрузке.

Для этого вы можете внести изменения в /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 -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 с помощью одной команды или одного файла журнала.

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

Приведенные выше примеры предоставляют вам отправную точку для устранения неполадок.

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