it-swarm-ru.tech

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

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

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

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

123
alex

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

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

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

50
forcefsck

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

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

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

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

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

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

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

127
Nicolas de Fontenay

Вы должны изучить 2 вещи:

  1. Вывод последней команды -x
  2. Файлы журналов в /var/log/

Используйте эти 2 команды и продолжайте читать для получения дополнительной информации.

last -x | head | tac

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'

1) Относительно вывода последней команды -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)    

2) По поводу логов в/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, чтобы инвертировать порядок, чтобы нас не смущал тот факт, что последние печатаются от самого недавнего до наименее недавнего события.

26
ndemou

Некоторые возможные файлы журналов для изучения: (нашел систему 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 - ваш друг.

11
user6148

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

last -x shutdown reboot
8
jhvaras

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

У меня была похожая потребность в 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]; затем 
 # Совместимость со старым скриптом конфигурации из пакета acpid 
 /etc/acpi/powerbtn.sh
Elif [-x /etc/acpi/powerbtn.sh.dpkg-bak] ; затем 
 # Совместимость со старым скриптом конфигурации из пакета acpid 
 #, который все еще существует, потому что он был изменен администратором 
 /etc/acpi/powerbtn.sh.dpkg-bak 
 else 
 # Нормальное обращение. 
/sbin/shutdown -h -P теперь "Нажата кнопка питания" 
 fi 

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

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

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

 #!/bin/sh 
 регистратор в /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

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

8
Stéphane Gourichon

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

4
sazary

В моем случае у меня была проблема с перегревом, и я нашел журнал в/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
1
luandrea

Просто вставьте это в мой KVM VM (где я задавался вопросом, выполняла ли перезагрузка хоста чистое отключение гостей), я нашел то, что мне нужно в /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)

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

[email protected]:~#
Broadcast message from [email protected]
        (unknown) at 22:25 ...

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

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

0
LanceBaynes