Як дізнатись із журналів, що спричинило відключення системи?

Наприклад, я бачу це в /var/log/messages:

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

Чи є спосіб з’ясувати, що спричинило зупинку? Наприклад, це було запущено з консолі, чи хтось натиснув кнопку живлення тощо?

Тільки кореневі пільгові програми можуть виграшно вимкнути систему. Отже, коли система закривається нормально, це або користувач з привілеями root, або сценарій 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його man man сторінки:

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 і зауважую, що в журналі немає чіткого і явного повідомлення, що трохи дивно.

Прорив /var/logможе сказати час вимкнення машини, показувати належне відключення демонів тощо, але не початкова причина.

shutdown[25861]: shutting down for system halt

Інші рішення, згадані ( last -x), не дуже допомогли.

Дивлячись, як це працює

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

якщо [-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
ще
    # Нормальна керованість.
    / sbin / shutdown -h -P зараз "Натиснута кнопка живлення"
фі

Зауважте, що явний текст заданий як параметр shutdownкоманди. Я б очікував, що ця рядок автоматично записується програмою відключення.

Налаштування для кращих журналів

У будь-якому випадку, щоб отримати явне повідомлення, я поклав текст нижче (як корінь) у щойно створений /etc/acpi/powerbtn.shвиконаний файлchmod a+x /etc/acpi/powerbtn.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

Тепер це явне повідомлення в журналі.

У мене просто незграбна ідея, але, можливо, вона працює для вас: введіть команду 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

Просто зафіксуйте це на моєму VM 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

в моєму випадку це було програмне забезпечення, що відключало сервер.

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