Как узнать из логов, что вызвало отключение системы?

Например, я вижу это в /var/log/messages:

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

Есть ли способ узнать, что вызвало отключение? Например, он запускался с консоли или кто-то нажимал кнопку питания и т. Д.?

Только привилегированные программы root могут корректно завершить работу системы. Поэтому, когда система выключается обычным способом, это либо пользователь с правами root, либо сценарий acpi. В обоих случаях это можно узнать, проверив логи. Выключение acpi может быть вызвано нажатием кнопки питания, перегревом или разрядкой аккумулятора (ноутбука). Я забыл третью причину - программное обеспечение ИБП при сбое электропитания, которое все равно отправит предупреждение.

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

Так что, если это нормальное отключение, оно будет зарегистрировано, если это вторжение ... удачи, и если это холодное отключение, ваш лучший шанс узнать это контролировать и контролировать окружающую среду.

Попробуйте следующие команды:

Показать список последних записей перезагрузки: last reboot | less

Показать список последних записей о выключении: last -x | less

или точнее: last -x | grep shutdown | less

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

Я нашел этот ресурс в Интернете. Это может быть полезно для вас:

Как узнать, кто или что остановило мою систему

Есть несколько вещей, чтобы проверить:

Проверьте вывод последней команды -x

Запустите эту команду * и сравните вывод с примерами ниже:

last -x | head | tac

Примеры нормального выключения

Обычное выключение и включение питания выглядит следующим образом (обратите внимание, что у вас есть событие выключения, а затем событие загрузки системы):

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)       

В некоторых случаях вы можете увидеть это (обратите внимание, что нет никаких строк о завершении работы, но система находилась на уровне выполнения 0, который является «состоянием остановки»):

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)   

Неожиданные примеры выключения

Неожиданное отключение из-за потери питания выглядит следующим образом (обратите внимание, что у вас есть событие загрузки системы без предшествующего события завершения работы системы):

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)    

Изучите журналы в / var / log

Команда bash для фильтрации наиболее интересных сообщений журнала:

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'

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

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

Когда система выключается, потому что пользователь нажал кнопку питания, вы получаете журналы, подобные этому:

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

Только когда система выключается по порядку, вы получаете журналы, подобные этому:

rsyslogd: ... exiting on signal 15

Когда система выключается из-за перегрева, вы получаете журналы, подобные этим:

critical temperature reached...,shutting down

Если у вас есть ИБП и запущен демон для мониторинга питания и выключения, вы, очевидно, должны проверить его журналы (NUT регистрирует / var / log / messages, но apcupsd входит / var / log / apcupsd *)

Примечания

*: Вот описание lastсо страницы руководства :

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
[...]
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down. 

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

Некоторые возможные файлы журналов для изучения: (найдена система Ubuntu, но я надеюсь, что они присутствуют в большинстве систем Linux / Unix)

/var/log/debug
/var/log/syslog (will be pretty full and may be harder to browse)
/var/log/user.log
/var/log/kern.log
/var/log/boot

Опять же, эти файлы журналов присутствуют в системе Ubuntu, поэтому имена файлов могут отличаться. Команда tailтвой друг.

Упростите, используя lastотображение записей о выключении системы и изменений уровня выполнения, а также фильтрацию shutdownи reboot:

last -x shutdown reboot

Не полностью удовлетворяет

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

Grep через /var/logсообщит время, когда машина была выключена, покажет правильное отключение демонов и т. Д., Но не будет исходной причиной.

shutdown[25861]: shutting down for system halt

Другие упомянутые решения ( last -x) не сильно помогли.

Смотря как это работает

Чтение, /etc/acpi/powerbtn-acpi-support.shкоторое включает в себя:

if [-x /etc/acpi/powerbtn.sh]; тогда
    # Совместимость со старым скриптом config из пакета acpid
    /etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; тогда
        # Совместимость со старым скриптом config из пакета acpid
    # который все еще существует, потому что он был изменен администратором
        /etc/acpi/powerbtn.sh.dpkg-bak
еще
    # Нормальная обработка.
    / sbin / shutdown -h -P теперь "кнопка питания нажата"
фи

Обратите внимание, что явный текст задан в качестве параметра shutdownкоманды. Я ожидаю, что эта строка будет автоматически записана программой завершения работы.

Регулировка для лучших журналов

В любом случае, чтобы получить явное сообщение, я поместил текст ниже (как root) во вновь созданный /etc/acpi/powerbtn.shисполняемый файл сchmod a+x /etc/acpi/powerbtn.sh

#! / Bin / ш
войти в /etc/acpi/powerbtn.sh, предположительно, «кнопка питания нажата»
    / sbin / shutdown -h -P теперь "кнопка питания нажата"

Выполнение этого таким образом, вероятно, внесет более длительные изменения, чем изменение /etc/acpi/powerbtn-acpi-support.sh. Последний вариант, вероятно, потеряет свой эффект при следующем обновлении пакета acpi-support-base.

Обратите внимание, что Ubuntu 14.04 делает это по-другому ( /etc/acpi/powerbtn.shуже существует с содержимым, отличным от acpidпакета). Кроме того, Debian 8, вероятно, делает это по-другому. Не стесняйтесь предлагать варианты.

Прибыль!

И теперь, когда кнопка питания нажата, появляется строка, как показано ниже /var/log/messages, /var/log/syslogи /var/log/user.log:

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

Теперь это явное сообщение в журнале.

У меня просто неуклюжая идея, но, может быть, она вам подходит: введите команду lastи проверьте информацию для всех пользователей. затем отфильтруйте пользователей с необходимыми разрешениями halt, которые были зарегистрированы в данный момент. затем проверьте их .bash_historyфайл, чтобы увидеть, остановились ли они или нет.

В моем случае у меня была проблема с перегревом, и я нашел журнал в / var / log / syslog с помощью 'grep shut *' в папке / var / log.

Зарегистрированная ошибка была такой:

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down

Просто вставьте это в мою виртуальную машину KVM (где я задавался вопросом, выполняла ли перезагрузка хоста чистое отключение гостей), я нашел то, что мне было нужно /var/log/auth.log(в дополнение к last -x shutdownпоказу того же самого). Там появились эти строки:

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on 0.0.0.0 port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -xпоказывает эти строки, обратите внимание, что они печатаются в самом последнем порядке (т. е. сначала читают последнюю строку, а затем идут вверх), но из-за сброса часов (23:56 до загрузки, 23:55 после) в предыдущих строках также видно, что порядок выглядит немного странно:

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

Со своей стороны, проверяя, что гости корректно закрываются при загрузке хоста, я также могу просто войти в систему (ssh) одного из гостей и остаться там, когда я загружаю хост, получая эти строки в терминале:

root@Web:~#
Broadcast message from root@Web
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.

псевдонимом завершения работы сценария
сценарий должен передать все параметры и т. д. исходному исполняемому файлу завершения работы
НО: сценарий должен записать эти

cat /usr/adm/syslog

в моем случае это было программное обеспечение ups, закрывающее сервер.

/etc/rc.d/7/upsd.boot