гипервизор не дождался выключения гостя и по таймауту

А на гипервизоре не проще эту инфу собрать?

А на гипервизоре не проще эту инфу собрать?

Нет, Я привёл пример с гипервизором в качестве примера. Приведу другой - погас свет. При загрузке ОС должна определить что предыдущее выключение было некорректным и сформировать лог.

Вот не могу я поверить в то, что нет в Linux способа прочитать информацию о статусе предыдущих выключений ОС.

Чем корректное завершение работы от некорректного отличается? Смею предположить, что при «некорректном» завершении работы какой-то критичный демон не завершает свою работу как надо. Вот логи этого демона и смотри.

last -x reboot shutdown
journalctl --list-boots

man systemd-journald
systemd-journald writes entries to files in /run/log/journal/machine-id/ or /var/log/journal/machine-id/ with the ".journal" suffix. If the daemon is stopped uncleanly, or if the files are found to be corrupted, they are renamed using the ".journal~" suffix, and systemd-journald starts writing to a new file.

last не подходит.

Вот логи этого демона и смотри.

Можно пример?

last не подходит.

Почему?
Дайте вывод этой команды:

last -x reboot shutdown

Как в этом логе можно найти 8 падений питания в день "Mon Jan 11"?

reboot   system boot  2.6.32-45-server Fri Jan 15 12:14 - 12:15  (00:00)
reboot   system boot  2.6.32-45-server Tue Jan 12 10:57 - 12:15 (3+01:17)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:50 - 12:15 (3+18:25)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:38 - 12:15 (3+18:37)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:36 - 12:15 (3+18:39)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:34 - 12:15 (3+18:40)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:32 - 12:15 (3+18:42)
shutdown system down  2.6.32-45-server Mon Jan 11 17:32 - 10:19  (00:00)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:30 - 11:12  (00:01)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:29 - 11:12  (00:03)
shutdown system down  2.6.32-45-server Mon Jan 11 17:29 - 10:19  (00:00)
shutdown system down  2.6.32-45-server Mon Jan 11 17:29 - 10:19  (00:00)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:07 - 19:04  (00:21)
shutdown system down  2.6.32-45-server Mon Jan 11 17:07 - 09:49  (00:00)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:04 - 19:02  (00:02)
reboot   system boot  2.6.32-45-server Mon Jan 11 17:03 - 19:02  (00:04)
shutdown system down  2.6.32-45-server Tue Jul 21 19:19 - 13:59 (173+21:44)
shutdown system down  2.6.32-45-server Thu Jul 21 19:19 - 10:19  (00:00)
reboot   system boot  2.6.32-45-server Tue Jul 21 19:17 - 13:58  (00:01)
shutdown system down  2.6.32-45-server Tue Jul 21 19:17 - 13:38  (00:00)

Ну например, у тебя на сервере крутится mysql. Чем критично некорректное выключение сервера? Тем, что могут появиться проблемы в работе субд. Вот и смотри логи mysql, корректно оно легло или нет.

mysql

Есть сервера и без SQL. Разводить зоопарк методов для определения корректности выключения - не вариант, ровно как и установка SQL только ради мониторинга. Я задал сюда вопрос именно потому что не смог найти в чистой системе чего-то подобного логам SQL.

Какая тебе разница, как выключилась система? Тебе важно то, как «выключился» софт.

Более всего детектор плохого завершения работы нужен для оповещения администратора о внезапном и незапланированном выключении серверов.

Мы озаботились этим уведомлением из-за одной нештатной ситуации. В тот раз сервера упали по питанию (не выдержал UPS). Когда электросеть восстановилась сервера успешно стартовали и начались проблему у клиентов. Оказалось, что в нужный момент в сети не оказалось серверов.

В связи с этим оказался востребован лог некорректных завершений работы ОС. Желательно, с указанием даты-времени незапланированного выключения, чтобы можно было точно выяснить: когда система незапланировано упала и через какой промежуток времени поднялась обратно.

Написать сценарии - не проблема, нужно только выяснить время падения ОС.

Более всего детектор плохого завершения работы нужен для оповещения администратора о внезапном и незапланированном выключении серверов.

Настрой ЛЮБОЙ мониторинг. Если сервер перезагрузился, но администраторы его не трогали, знпчит это незапланированный и внезапный сбой, да.

Если сервер перезагрузился, но администраторы его не трогали, знпчит это незапланированный и внезапный сбой

Это само собой разумеется. Вопрос в том, КАК определить время падения сервера? Какой мониторинг позволяет сделать это? Утилита last, как видно, не позволяет.

Вопрос в том, КАК определить время падения сервера? Какой мониторинг позволяет сделать это?

Да любой. Ты можешь хоть по крону каждую минуту писать в лог «я жив!», таким образом определив время остановки сервера, но это никак не поможет понять причину остановки.

Вообще (я тоже подписан на тред - интересно) если бы мне надо было решение «здесь и сейчас» - я бы накидал какой-нибудь простенький демон, который бы просто при запуске писал в лог «я стартанул», при остановке - «я остановился» - таким образом можно было бы понять, завершил ли сервер свою работу корректно (тогда можно смотреть в last и подобное чтоб найти того, кто сервак остановил) или просто сдох из-за пропадания питания. Но все-таки мне интересно какое-нибудь изкоробочное решение.

КАК определить время падения сервера

Какой системой мониторинга вы пользуетесь?

вы хотите заббикс

Ежеминутный лог «я жив!»

Терзать диск скриптом/кроном или писать демон - не вариант. Систем много и все они немного разные... В данном случае интересует решение мониторинга «из коробки».

Какой системой мониторинга вы пользуетесь?

Пока что никакой.

Может, есть резон влезть в сценарии init и дописать туда что-нибудь?

А у заббикса есть флаг или лог "некорректное завершение работы системы"?

Даже если есть - заббикс не является решением «из коробки», а хочется именно коробочного решения.

Ну и о чем говорить, если «заббикс - не из коробки» а другого нет НИЧЕГО

для гурманов есть вынос логов на удаленную машину, есть кастомные триггеры (в дополнение к стандартным «недоступен», «был перезагружен»)

Систем много и все они немного разные...

И не смогу в простой «демон» на bash на несколько строк?

В данном случае интересует решение мониторинга «из коробки».

Любой мониторинг. Деже тот же «примитивный» munin может «из коробки» смотреть uptime и покажет что хост был перезагружен. Всякие zabbix и прочие это подавно умеют.

Вариант с «демоном» позволит узнать почему хост ребутнулся, сам мониторинг (в общем случае) лишь отобразит факт перезапуска.

«демон» на bash

Можно и демон на шелле наваять. Только он должен быть простой как пробка. А то разные шеллы один и тот же код могут выполнять немного по-совему.

Вариант с «демоном» позволит узнать почему хост ребутнулся

Причины скриптом собирать - не очень надёжно. Нужно очешь хорошо знать что куда и в каких случах пишется. Однако, это уже не так важно. Главное - чтобы админ мог при старте ОС узнать что хост внезапно бахнулся в час X на Y-минуте.

Просто отлично. Закрывай тред.

И, простите, почему?

Причин для выключения сервера может быть очень и очень много. И для отправки в теле письма описания причины действительно нужна система мониторинга, типа того же заббикса. А мне нужно не описание причины по которой грохнулся сервер, а отметка о времени и корректности завершении работы ОС. Я не просто так в начале треда упомянул маздай, где подобный флажок выключения ЕСТЬ.

Фактически достаточно будет лога такого вида:

Дата       Врея     Статус
10.10.2016 09:35:18 Нормально
10.10.2016 10:05:00 Нормально
10.10.2016 19:07:56 Система упала
10.11.2016 01:09:01 Нормально

нештатные ситуации я условно поделю на 2 типа:

1) Внезапное отключение электропитания
2) Системный сбой

В первом случае, САМЫЙ гарантированно работающий метод - это писать каждую минуту в файл. Иначе без электропитания невозможно сохранить никакую информацию без внешних устройств с автономным питанием.

Во втором случае, когда «система упала», как вы говорите, надо смотреть в kernel log. Когда питание есть, и система работать дальше не может - посмотрите где находится этот лог для вашей ОС. Например: http://askubuntu.com/questions/104771/where-are-kernel-panic-logs

Ну и да, если вам нужно качественное и комплексное решение - его надо писать своими силами либо обращаться в job.

Спасибо за информацию

«качественное и комплексное решение» нас будет инетесовать, но не на данном этапе. Так что, получается, в Linux точно нет никакого флага, который бы поднимался при порректром останове ОС?

корректная остановка записывается в last

некорректная остановка (точнее отладочные данные о ней) - в лог ядра.

а вообще, если у вас критическая система - я бы взял какое-нибудь автономное устройство с низким энергопотреблением (типа одноплатника RPI), которое будет постоянно пинговать нужные хосты

Как только пинг пропал - в лог пишутся данные.

Просто, эффективно, отказоустойчиво. Для надежности можно продублировать сей девайс.

Потому что вопрос в том «КАК определить время падения сервера».

Ответ простой. По почтовым алертам заббикса.

Подводя итог

В ОС Linux из коробки нет подробного журнала выключений.

Есть команда last, из выхлопа которой можно определить время запланированных выключений или перезагрузок, однако на случаи падения электричества или KernelPanic этот вариант не подходит.

Для мониторинга нештатного выключения есть 3 варианта:

1) заббикс - установка полного мониторинга,

2) писать ежеминутно файл с текущими датой и временем - самый тупой, но самый рабочий способ, и

3) пинговать хост, записывая момент, когда хост перестал отзываться.

В systemd всё есть:
Журнал выключений (комментарий)

В выхлопе last только корректные события от псевдопользователей reboot и shutdown.

dpkg -L systemd | grep journalctl

dpkg-query: пакет «systemd» не установлен

apt-get install systemd

Пакет systemd недоступен, но упомянут в списке зависимостей другого пакета. Это может означать, что пакет отсутствует, устарел, или доступен из источников, не упомянутых в sources.list Однако следующие пакеты могут его заменить: systemd-services systemd-services:i386

E: Для пакета «systemd» не найден кандидат на установку

apt-get install systemd-services
dpkg -L systemd | grep journalctl

dpkg-query: пакет «systemd» не установлен

dpkg -L systemd-services | grep journalctl

пусто, как и

which journalctl

Ох... страна непуганных пользователей... Анализируй вывод строк, предшествующих первой от начала загрузки. Можешь, например, искть «init: Switching to runlevel» (это если init класический; как в новомоднем systemd - не знаю). Если это ресет, то не будет нормального завершения процессов перед загрузкой.

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

А это не верно.

Поставь виртуалку и грохни её раз десять к ряду. Ты заметишь, что при загрузке ФС ругается далеко не каждый раз.

прежде чем говорить о корректном «выключении», сначала определимся, что такое корректное «включение» и последующая корректная с нашей точки зрения работа
наверное нет ничего плохого в установки заббикс агента для того, чтобы быть уверенным в том, что сервер выполняет именно ту работу, которую от него ожидают.
тогда с помощью того же заббикса можно узнать, корректно ли завершились те сервисы, ради которых и работает сервер.
хотя, я знаю людей, которым достаточно с утра зайти проверить жива ли машина и ждать звонка пользователей.
с тем же успехом они могли ставить пинг до сервера, эффект такой же, зато хотя бы заходить на десятки серверов не нужно.
к чему это я? если вас интересует корректность - нужна система мониторинга

>зато хотя бы заходить на десятки серверов не нужно

1) У нас не такой большой парк серверов.

2) При выключении гипервизора тот отправляет гостям сигнал о выключении. Нас интересует только одно: ВМ успела выключиться самостоятельно, или гипервизор грохнул её процесс по таймауту?

3) Данная информация должна собираться на гостях, а не гипервизоре.

Для этого заббикс не очень-то нужен... В данном конкретном случае устроит даже демон на шелле (главное, чтобы был универсален и не требовал установки довесочного софта).

устроит даже демон на шелле

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

>банально через создание lock-файла при загрузке

Ты какие файлы имеешь в виду? Те, что в /var/lock?

/var/lock?

Да, как вариант.
Главное, чтобы не на tmpfs.