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

<p>например. я вижу это в <code>/var/log/messages</code>:</p><pre><code>mar 01 23:12:34 hostname shutdown: shutting down for system halt </code></pre><p>есть ли способ узнать, что вызвало отключение? например. он запускался с консоли, или кто-то нажимал кнопку питания и т. д.?</p>

<p>только привилегированные программы root могут корректно завершить работу системы. поэтому, когда система выключается обычным способом, это либо пользователь с правами root, либо сценарий acpi. в обоих случаях это можно узнать, проверив логи. выключение acpi может быть вызвано нажатием кнопки питания, перегревом или разрядкой аккумулятора (ноутбука). я забыл третью причину - программное обеспечение ибп при сбое электропитания, которое все равно отправит предупреждение.</p><p>недавно у меня была система, которая начинала многократно отключаться, оказалось, что она перегрелась, и mobo был настроен на раннее отключение. у системы не было возможности сохранить логи, но, к счастью, мониторинг температуры системы показал, что она начинает увеличиваться непосредственно перед выключением.</p><p>так что, если это нормальное отключение, оно будет зарегистрировано, если это вторжение ... удачи, и если это холодное отключение, ваш лучший шанс узнать это контролировать и контролировать окружающую среду.</p>

<p>попробуйте следующие команды:</p><p>показать список последних записей перезагрузки: <code>last reboot | less</code></p><p>показать список последних записей о выключении: <code>last -x | less</code></p><p>или точнее: <code>last -x | grep shutdown | less</code></p><p>вы не будете знать, кто это сделал, однако. если вы хотите знать, кто это сделал, вам нужно будет добавить немного кода, что означает, что вы узнаете в следующий раз.</p><p>я нашел этот ресурс в интернете. это может быть полезно для вас:</p><p> <a href="https://web.archive.org/web/20170904210829/http://scofaq.aplawrence.com:80/faq\_scotec1haltcatch.html">как узнать, кто или что остановило мою систему</a> </p>

<p>вы должны изучить 2 вещи:</p><ol> <li>вывод <em> последней команды -x </em></li> <li>файлы журналов в <em>/var/log/</em></li> </ol><p>используйте эти 2 команды и продолжайте читать для получения дополнительной информации.</p><pre><code>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' </code></pre><h2>1) относительно вывода последней команды -x</h2><p>запустите эту команду * и сравните вывод с примерами ниже:</p><pre><code>last -x | head | tac </code></pre><h3>примеры нормального выключения</h3><p>обычное выключение и включение питания выглядит следующим образом (обратите внимание, что у вас есть событие выключения, а затем событие загрузки системы):</p><pre><code>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) </code></pre><p>в некоторых случаях вы можете увидеть это (обратите внимание, что нет никаких строк о завершении работы, но система находилась на уровне выполнения 0, который является "состоянием остановки"):</p><pre><code>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) </code></pre><h3>неожиданные примеры выключения</h3><p>неожиданное отключение из-за потери питания выглядит следующим образом (обратите внимание, что у вас есть событие загрузки системы без предшествующего события завершения работы системы):</p><pre><code>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) </code></pre><h2>2) по поводу логов в/var/log /</h2><p>команда bash для фильтрации наиболее интересных сообщений журнала:</p><pre><code>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' </code></pre><p>когда происходит неожиданное отключение питания или аппаратный сбой, файловые системы не будут должным образом размонтированы, поэтому при следующей загрузке вы можете получить журналы, подобные следующим:</p><pre><code>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. </code></pre><p>когда система выключается, потому что пользователь нажал кнопку питания, вы получаете журналы, подобные этому:</p><pre><code>systemd-logind: power key pressed. systemd-logind: powering off... systemd-logind: system is powering down. </code></pre><p>только когда система выключается по порядку, вы получаете журналы, подобные этому:</p><pre><code>rsyslogd: ... exiting on signal 15 </code></pre><p>когда система выключается из-за перегрева, вы получаете журналы, подобные этим:</p><pre><code>critical temperature reached...,shutting down </code></pre><p>если у вас есть ибп и запущен демон для мониторинга питания и выключения, вы, очевидно, должны проверить его журналы (nut регистрирует/var/log/messages, но apcupsd входит/var/log/apcupsd *)</p><hr><p><strong>примечания</strong></p><p>*: вот описание <code>last</code> со страницы руководства:</p><pre><code>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. </code></pre><p>мы используем <code>head</code>, чтобы сохранить последние 10 событий, и мы используем <code>tac</code>, чтобы инвертировать порядок, чтобы нас не смущал тот факт, что последние печатаются от самого недавнего до наименее недавнего события.</p>

<p>некоторые возможные файлы журналов для изучения: (нашел систему ubuntu, но я надеюсь, что они присутствуют в большинстве систем linux/unix)</p><pre><code>/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 </code></pre><p>опять же, эти файлы журналов присутствуют в системе ubuntu, поэтому имена файлов могут отличаться. команда <code>tail</code> - ваш друг.</p>

<p>упростите, используя <code>last</code>, отображая записи о завершении работы системы, изменения уровня выполнения и фильтрацию по <code>shutdown</code> и <code>reboot</code>:</p><pre><code>last -x shutdown reboot </code></pre>

<h2>не полностью удовлетворяющий</h2><p>у меня была похожая потребность в debian 7.8, и я заметил, что в журнале нет четкого и явного сообщения, что немного удивляет.</p><p>grep через <code>/var/log</code> сообщит время, когда машина была выключена, покажет правильное отключение демонов и т. д., но не будет начальной причиной.</p><pre><code>shutdown[25861]: shutting down for system halt </code></pre><p>другие упомянутые решения (<code>last -x</code>) не сильно помогло.</p><h2>смотря как работает</h2><p>чтение <code>/etc/acpi/powerbtn-acpi-support.sh</code> который включает в себя:</p><pre> 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 </pre><p>обратите внимание, что в качестве параметра команды <code>shutdown</code> указан явный текст. я ожидаю, что эта строка будет автоматически записана программой завершения работы.</p><h2>регулировка для лучших журналов</h2><p>в любом случае, чтобы получить явное сообщение, я поместил текст ниже (как root) во вновь созданный <code>/etc/acpi/powerbtn.sh</code> сделал исполняемым с <code>chmod a+x /etc/acpi/powerbtn.sh</code></p><pre> #!/bin/sh регистратор в /etc/acpi/powerbtn.sh, предположительно "кнопка питания нажата" /sbin/shutdown -h -p сейчас "кнопка питания нажимается " </pre><p>выполнение этого таким образом, вероятно, внесет более длительные изменения, чем изменение <code>/etc/acpi/powerbtn-acpi-support.sh</code>. последний вариант, вероятно, потеряет свой эффект при следующем обновлении пакета <code>acpi-support-base</code>.</p><p>обратите внимание, что ubuntu 14.04 делает это по-другому (<code>/etc/acpi/powerbtn.sh</code> уже существует с другим содержимым из пакета <code>acpid</code>). кроме того, debian 8, вероятно, делает это по-другому. не стесняйтесь предлагать варианты.</p><h2>прибыль!</h2><p>и теперь, когда кнопка питания нажата, строка, как показано ниже, отображается в <code>/var/log/messages</code>, <code>/var/log/syslog</code> а также <code>/var/log/user.log</code>:</p><pre><code>logger: in /etc/acpi/powerbtn.sh, presumably power button pressed </code></pre><p>теперь это явное сообщение в журнале.</p>

<p>у меня просто неуклюжая идея, но, может быть, она вам подходит: введите команду <code>last</code> и проверьте информацию для входа всех пользователей. затем отфильтруйте пользователей с разрешениями, необходимыми для <code>halt</code>, которые были зарегистрированы в этот момент. затем проверьте их <code>.bash\_history</code> файл, чтобы увидеть, остановились ли они или нет.</p>

<p>в моем случае у меня была проблема с перегревом, и я нашел журнал в/var/log/syslog с помощью 'grep shut *' в папке/var/log.</p><p>зарегистрированная ошибка была такой:</p><pre><code>feb 23 15:59:49 luca-lifebook-a530 kernel: [24746.497174] thermal thermal\_zone0: critical temperature reached(99 c),shutting down </code></pre>

<p>просто вставьте это в мой kvm vm (где я задавался вопросом, выполняла ли перезагрузка хоста чистое отключение гостей), я нашел то, что мне нужно в <code>/var/log/auth.log</code> (вдобавок к <code>last -x shutdown</code> показывает то же самое). там появились эти строки:</p><pre><code>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. </code></pre><p><code>last -x</code> показывает эти строки, обратите внимание, что они печатаются в <em>самый последний-первый</em> порядок (т.е. сначала читают последнюю строку, а затем идут вверх), но из-за сброса часов (23: 56 перед загрузкой, 23:55 после) также видно в предыдущих строках, порядок выглядит немного изумительным:</p><pre><code>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) </code></pre><p>со своей стороны, проверяя, чтобы гости были корректно закрыты при загрузке host, я также мог просто войти в систему (ssh) одного из гостей и остаться там, когда я загружаю host, получая эти строки в терминале:</p><pre><code>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. </code></pre>

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