Как определить причину перезагрузки linux

Как определить причину перезагрузки linux

Здравствуйте, prrt, Вы писали:

P>В один прекрасный момент сервер самопроизвольно перезагрузился. В логах ничего нет, при просмотре journalctl всё идет как обычно, потом одна запись:
P>— Reboot —
P>и дальше обычный лог загрузки системы. После перезагрузки сервер работает как обычно.
P>Подскажите, как определить, из-за чего произошел reboot? Возможно ли это из-за какого-то программного сбоя (хотя никаких segmentation fault не было) или такая запись в логе означает, что сервер перезагрузили вручную кнопкой?

Отключение кнопкой пишется в логах, если программный сбой, то не segmentation fault, а kernel panic.
Выше отписано, что это сервер, посмотри в логах ipmi-я ошибки или предупреждения. Есть шансы, что аппаратный сбой.

Вообще если это стабильный и мейнстрим linux (red hat / debian) со штатным ядром, без левых драйверов, то вероятность kernel panic стремиться к нулю. Самый вероятный вариант — сбой железа (вероятней всего память). Менее вероятный — неудачная конфигурация железа, левые дрова. Маловероятно, но возможно и озвученное Stanislaw K идея.

	От:	prrt
	Дата:	08.09.15 06:24
Оценка:

	От:	Stanislaw K
	Дата:	08.09.15 06:46
Оценка:

Здравствуйте, prrt, Вы писали:

P>В один прекрасный момент сервер самопроизвольно перезагрузился. В логах ничего нет, при просмотре journalctl всё идет как обычно, потом одна запись:
P>— Reboot —
P>и дальше обычный лог загрузки системы. После перезагрузки сервер работает как обычно.
P>Подскажите, как определить, из-за чего произошел reboot? Возможно ли это из-за какого-то программного сбоя (хотя никаких segmentation fault не было) или такая запись в логе означает, что сервер перезагрузили вручную кнопкой?

злоумышленники установили руткит?

	От:	prrt
	Дата:	08.09.15 06:59
Оценка:

	От:	Stanislaw K
	Дата:	08.09.15 07:22
Оценка:

Здравствуйте, prrt, Вы писали:

SK>>злоумышленники установили руткит?
P>Для этого, как я понимаю, нужно загрузить ОС, войти в неё и что-то там сделать плохое, т.е. надо знать пароли, успеть подчистить логи. Либо подключить загрузочный диск, загрузиться с него, и потом что-то записать на системный. Но это как-то слабо верится. Да и сервер размещен в дата-центре,

Для этого не надо иметь физического доступа, знать пароли и чистить логи.

Нужно удаленно, по сети, «подключится». Залогиниться по ssh или воспользоваться уязвимостью веб сайта или фтп. или еще что то.
Что то спокойно делать несколько недель. воспользоваться уязвимостью установленного пакета ПО. повысить привилегии. установить свое ПО. и т.д.

3-4 минуты, вполне возможно что злоумышленник перезагрузился, почистил логи и перезагрузился еще раз. теперь он тоже имеет контроль над твоей системой.

Но это только версия, конечно. Обычно(с) логи не чистят. Или чистят не все логи.

P>зачем кто-то там будет этим заниматься?

Потому что может.

P>Время, ушедшее на ребут составляет около 3-4 минут. Вроде многовато для простого reboot, может просто питание отключилось на эти несколько минут?

А что говорит датацентр? 3-4 минуты отключения питания, это ахтунг, и повод 50% скидки на следующий квартал.

	От:	prrt
	Дата:	08.09.15 12:51
Оценка:

Здравствуйте, Stanislaw K, Вы писали:

SK>А что говорит датацентр? 3-4 минуты отключения питания, это ахтунг, и повод 50% скидки на следующий квартал.

Дата-центр утверждает, что никаких работ не проводилось и питание не отключалось. Странно всё это. И, главное, непонятно, что сейчас еще можно сделать, чтобы докопаться до истины.

	От:	Stanislaw K
	Дата:	08.09.15 13:48
Оценка:

Здравствуйте, prrt, Вы писали:

SK>>А что говорит датацентр? 3-4 минуты отключения питания, это ахтунг, и повод 50% скидки на следующий квартал.

P>Дата-центр утверждает, что никаких работ не проводилось и питание не отключалось. Странно всё это. И, главное, непонятно, что сейчас еще можно сделать, чтобы докопаться до истины.

Еще большой вопрос, до какой истины ты хочешь докопаться?

Забрать с хоста все логи за последний месяц и внимательно читать. Логи хоста хранились только на нем? на удаленный syslog не копировались?

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

Нужно взять список используемого ПО, взять security bulleten и читать читать читать..

Но вопрос прежний — до какой истины ты хочешь докопаться? Зачем? Какую цель преследуешь?

	От:	prrt
	Дата:	08.09.15 16:14
Оценка:

Здравствуйте, Stanislaw K, Вы писали:

SK>Еще большой вопрос, до какой истины ты хочешь докопаться?
Найти причину перезагрузки.

SK>Забрать с хоста все логи за последний месяц и внимательно читать. Логи хоста хранились только на нем? на удаленный syslog не копировались?
Логи не копировались, уже изучены, ничего в них нет.

SK>Можно взять аналогичный сервер, установить на него такую же систему, с тем же набором ПО и патчей, обновить до такой же версии как на подозрительном сервере, и бинарно сравнить.
Вряд ли это вирус. На сервере нет ни веб сервера, ни почтового, ни ftp. Очень узкоспециализированный он, работает один демон, написанный специально для решения ряда задач исключительно для работы на этом сервере и всё.

SK>Нужно взять список используемого ПО, взять security bulleten и читать читать читать..
Не используется там никакое стандартное ПО. Голый линукс и специализированный демон.

SK>Но вопрос прежний — до какой истины ты хочешь докопаться? Зачем? Какую цель преследуешь?
Найти причину перезагрузки.

В общем, после продолжительного штудирования Интернета, нашел, что, такого рода перезагрузки обычно бывают в двух случаях:
— проблемы с питанием
— hardware problems.
Первый случай отрицают в дата-центре, второй чаще всего возникает по двум причинам:
— Плохая память (memtest в руки)
— Перегрев.
Для проверки перегрева надо будет поставить логирование всех параметров — температура процессоров, винчестеров и пр. Пока что из этого и буду исходить.

	От:	Stanislaw K
	Дата:	08.09.15 17:51
Оценка:

Здравствуйте, prrt, Вы писали:

SK>>Еще большой вопрос, до какой истины ты хочешь докопаться?
P>Найти причину перезагрузки.

SK>>Забрать с хоста все логи за последний месяц и внимательно читать. Логи хоста хранились только на нем? на удаленный syslog не копировались?
P>Логи не копировались, уже изучены, ничего в них нет.

За месяц? Внимательно?

SK>>Нужно взять список используемого ПО, взять security bulleten и читать читать читать..
P>Не используется там никакое стандартное ПО. Голый линукс и специализированный демон.

голый линукс — это ядро. ssh это уже ПО третьих производителей.

SK>>Но вопрос прежний — до какой истины ты хочешь докопаться? Зачем? Какую цель преследуешь?
P>Найти причину перезагрузки.

P>В общем, после продолжительного штудирования Интернета, нашел, что, такого рода перезагрузки обычно бывают в двух случаях:
P>- проблемы с питанием
P>- hardware problems.
P>Первый случай отрицают в дата-центре, второй чаще всего возникает по двум причинам:
P>- Плохая память (memtest в руки)

может быть, но как это возможно на сервере? без отметок в логах? сэкономили на памяти ECC RDRAM? это вообще не сервер а бытовой ПЦ?

P>- Перегрев.

В датацентре перегрев? Это ахтунг еще хуже пропадающего электричества.

snmp мониторинг какую температуру чипсета показывает? smartctl температуру жесткого диска?

P>Для проверки перегрева надо будет поставить логирование всех параметров — температура процессоров, винчестеров и пр. Пока что из этого и буду исходить.

Источник

ИТ База знаний

Курс по Asterisk

Полезно

— Узнать IP — адрес компьютера в интернете

— Онлайн генератор устойчивых паролей

— Онлайн калькулятор подсетей

— Калькулятор инсталляции IP — АТС Asterisk

— Руководство администратора FreePBX на русском языке

— Руководство администратора Cisco UCM/CME на русском языке

— Руководство администратора по Linux/Unix

Навигация

Серверные решения

Телефония

FreePBX и Asterisk

Настройка программных телефонов

Корпоративные сети

Протоколы и стандарты

Как узнать причину перезагрузки Linux

Что вызвало ребут?

4 минуты чтения

Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев.

Онлайн курс по Linux

Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps

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

Проверка времени перезагрузки

Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last

Проверка системных журналов

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

Для систем CentOS/RHEL журналы можно найти по адресу /var/log/messages , а для систем Ubuntu/Debian — по адресу /var/log/syslog . Для фильтрации или поиска конкретных данных можно использовать команду tail или любимый текстовый редактор.

Как видно из приведенных ниже журналов, такие записи предполагают завершение работы или перезагрузку, инициированную администратором или пользователем root . Эти сообщения могут варьироваться в зависимости от типа ОС и способа запуска перезагрузки или завершения работы, но вы всегда найдете полезную информацию, просматривая системные журналы, хотя этого не всегда может быть достаточно, чтобы определить причину.

Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов:

Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы.

Проверка журнала auditd

Для систем, использующих auditd – это отличное место для проверки различных событий с помощью инструмента ausearch . Используйте приведенную ниже команду для проверки последних двух записей из журналов аудита.

Появится сообщение о двух последних остановках или перезагрузках. Если это сообщает о SYSTEM_SHUTDOWN , за которым следует SYSTEM_BOOT , все должно быть хорошо. Но, если он сообщает две строки SYSTEM_BOOT подряд или только одно сообщение SYSTEM_BOOT , то, скорее всего, система некорректно завершила работу. Вывод при нормальной работе должен быть примерно следующим:

В приведенных ниже выходных данных перечислены два последовательных сообщения SYSTEM_BOOT , которые могут указывать на аварийное завершение работы, хотя результаты нужно скорректировать с данными системного журнала.

Анализ журнала systemd

Чтобы сохранить журнал системных логов на диске, необходимо иметь постоянный системный журнал, иначе логи будут очищаться при перезагрузке. Для этого можно либо внести изменения в /etc/systemd/journald.conf , либо создать каталог самостоятельно с помощью следующих команд:

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

Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала:

Вот его выходные данные на моем сервере:

Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте:

Здесь будет индексом, заданным в команде journalctl —list-boots в первом столбце.

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

Заключение

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

Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.

Мини — курс по виртуализации

Знакомство с VMware vSphere 7 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Источник