Как узнать причину выключения компьютера linux

Как узнать почему был выключен компьютер?

Домашний сервер почему-то выключился. Когда был на работе заходил на него через ssh, всё работало. Когда приехал домой он уже был выключен.

Свет дома скорее всего не отключали (часы на микроволновке не сбросились). Даже если и отключали, то в BIOS настроено чтоб при появлении электричества комп включался.

Собственно, очень хочется узнать почему он выключился. Как это можно сделать?

Смотрел /var/log/syslog, ничего интересного не заметил.

перегрелся процессор / перегрелся/сглючил чипсет / сглючила память / сглючил бп / сглючил линукс — что-либо из этого. узнать никак ты не сможешь. у меня было подобное когда-то, всё чаще и чаще пока блок питания не сдох окончательно (повздувались кондёры).

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

Во втором случае аналогичные действия, как и выше, производятся с кулером чипсета, если там только радиатор можно прикрутить кулер от старых процессоров, PI, AMD K-5, PII прямо к радиатору чипсета, если его вообще нет купить и приклеить.

В третьем случа провести тесты, проверить режим работы памяти с её паспортными параметрами, частота, напряжение и тайминги.

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

Так же стоит установить lm_sensors и проверять показания датчиков температуры, уровни стандартных напряжений питания, 12в, 3.3в, 5в, прочее.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Журнал выключений

В ос M$ есть журнал событий и с помощью проспотра которого можно выяснить — на сколько корректно выключался компьютер. В логах Linux не силён, но долгий гуглёж подсказал мне только утилиту last, по выхлопу которой история выключений стсиемы вообще не видна.

Поэтому хочу спросить — как встроенными средствами ОС можно посмотреть историю выключений Linux системы? В особенности меня интересует статус выключения — корректное завершение работы или система «упала».

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

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

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

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

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

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

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

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 не подходит.

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

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

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

mysql

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Как проверить дату выключения и перезагрузки в Linux

Как проверить дату выключения и перезагрузки в Linux

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

Последняя загрузка

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

Список всех перезагрузок системы

С помощью команды last вы можете выводить список после каждого перезагрузки системы.

Последняя перезагрузка

Если вы предпочитаете более сжатую версию, показывающую только последнюю загрузку компьютера, вы можете запустить head и добавить -1, указав вывод только на одну строку. Если вы предпочитаете загрузку до текущей, используйте -2 для получения обеих строк.

Выключения

Вывод списка выключений компьютера.

Последнее выключение

Как и в случае с предыдущими перезагрузками, можно настроить вывод head, чтобы получить только последнее выключение. Также, как и прежде, вы можете ввести другую цифру, например -3, чтобы получить последние три отключения.

Uptime

Наконец, когда вы хотите узнать, как долго работал ваш компьютер, вы можете использовать команду uptime, чтобы выяснить это. Объедините его с флагом -p, чтобы получить гораздо более удобочитаемый результат. Вы получите количество времени в днях, часах и минутах, которое ваш компьютер был включен с момента последней загрузки.

Надеюсь, с помощью приведенных выше команд вы сможете выяснить закономерность, или даже причину перезагрузки и выключения компьютера. Если задействованы другие программы, вы всегда можете проверить наличие определенных файлов журнала в «/var/log».

Спасибо, что читаете! Подписывайтесь на мои каналы в Telegram, Яндекс.Мессенджере и Яндекс.Дзен. Только там последние обновления блога и новости мира информационных технологий.

Респект за пост! Спасибо за работу!

Хотите больше постов? Узнавать новости технологий? Читать обзоры на гаджеты? Для всего этого, а также для продвижения сайта, покупки нового дизайна и оплаты хостинга, мне необходима помощь от вас, преданные и благодарные читатели. Подробнее о донатах читайте на специальной странице.

Заранее спасибо! Все собранные средства будут пущены на развитие сайта. Поддержка проекта является подарком владельцу сайта.

партнёры блога

telegram

Реклама

Последние

Рубрики

СЧЕТЧИКИ

РЕКЛАМА И ДОНАТЫ

Социальные сети

©2016-2021 Блог Евгения Левашова. Самое интересное и полезное из мира ИТ. Windows 10, Linux, Android и iOS. Обзоры программ и веб-сервисов. Статьи о мотивации и продуктивности.

Использование материалов разрешается с активной ссылкой на levashove.ru.

Данный блог является личным дневником, содержащим частные мнения автора. В соответствии со статьей 29 Конституции РФ, каждый человек может иметь собственную точку зрения относительно его текстового, графического, аудио и видео наполнения, равно как и высказывать ее в любом формате. Блог не имеет лицензии Министерства культуры и массовых коммуникаций РФ и не является СМИ, а, следовательно, автор не гарантирует предоставления достоверной, не предвзятой и осмысленной информации. Сведения, содержащиеся в этом блоге не имеют никакого юридического смысла и не могут быть использованы в процессе судебного разбирательства. Автор блога не несёт ответственности за содержание комментариев к его записям.

Источник

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

Курс по Asterisk

Полезно

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

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

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

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

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

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

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

Навигация

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

Телефония

FreePBX и Asterisk

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

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

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

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

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

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

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

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

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

Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе 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 и технологией виртуализации в авторском мини — курсе от Михаила Якобсена

Источник