как узнать причину перезагрузки линукс
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
🔥 Популярное
Руководство по команде grep в Linux
15 примеров команды PING для диагностики сети
Рекурсивно найти слово в файлах и папках Linux
15 примеров CURL в Linux
👌 Похожее
Мониторинг сервера с помощью Linux-dash
Лучшие HEX – редакторы для Linux
Текстовый редактор Vi
Как узнать причину перезагрузки Linux
Часто бывает, что на системе Linux произошла незапланированная или по неизвестным очевидным причинам, перезагрузка. Поиск и устранение первопричины может помочь предотвратить повторение таких проблем и избежать незапланированных простоев.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Есть несколько способов выяснить, что вызвало перезагрузку. В этой статье мы обсудим эти способы и способы использования доступных утилит и журналов в системе Linux для устранения таких сценариев.
Проверка времени перезагрузки
Чтобы посмотреть, когда именно произошла перезагрузка системы можно воспользоваться командами who и last
Проверка системных журналов
Кроме того, можно сопоставить время перезагрузки, которую требуется диагностировать, с системными сообщениями.
Ниже приведена одна такая команда, которую можно использовать для фильтрации системных журналов:
Зафиксированные события не всегда могут быть конкретными. Всегда отслеживайте события, которые дают признаки предупреждений или ошибок, которые могут привести к выключению или сбою системы.
Проверка журнала auditd
Анализ журнала systemd
После этого можно дополнительно перезагрузить систему для ввода нескольких записей перезагрузки в журнал, хотя это и не требуется.
Приведенную ниже команда позволяет выводить список записанных событий о загрузке из журнала:
Вот его выходные данные на моем сервере:
Как видно на рисунке, в системе есть несколько событий загрузки. Для дальнейшего анализа причины конкретной перезагрузки используйте:
В приведенных выше выходных данных можно просмотреть сообщения, зарегистрированные в журнале, и отследить аномалии, если таковые имеются.
Заключение
Не всегда можно определить причину перезагрузки Linux с помощью одной команды или из одного файла журнала. Поэтому всегда удобно знать команды и журналы, которые фиксируют события, связанные с системой, и могут сократить время, необходимое для поиска первопричины.
Приведенные выше примеры дают вам возможность начать поиск и устранение неисправностей. Используя комбинацию таких инструментов и журналов, вы можете быть уверены в том, что произошло и как перезагрузилась ваша система.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Как в Linux узнать даты выключения и перезагрузки компьютера
Может быть множество причин, почему вы хотите узнать, когда ваш компьютер на Linux выключался, перезапускался и как долго он работает. Эта информация может пригодиться в поиске и устранении проблем, которые могли случиться, когда вы не наблюдали за системой. К счастью, Linux в большинстве дистрибутивов тщательно в автоматическом режиме ведёт журнал системных событий. Доступ к сохранённой информации из командной строки также очень простой.
Последнее включение
Как узнать, когда Linux последний раз был включён? Если вам нужно определить время и дату последнего включения, то вы можете использовать команду who с опцией -b. Эта команда выведет точное число и время включения. Для выполнения команды не нужны привилегии root:
В какое время включался компьютер
С помощью команды last вы можете получить список, когда система включалась или перезагружалась. Это необязательно время, когда использовалась команда reboot, или когда нажималась кнопка «Перезагрузить» на рабочем столе. Это журнал событий, когда система была загружена.
Последнее включение Linux
Если вам нужно узнать только время последнего включения компьютера с Linux, то вы можете использовать предыдущую команду, но передать её вывод по конвейеру команде head с опцией -1, чтобы она вывела только одну строку. Чтобы узнать также и время предпоследней загрузки, то замените опцию на -2 — будут выведены две строки.
Выключения
Команда last работает аналогичным образом и для выключений. Она перечисляет случаи, когда компьютер был полностью выключен. Эта команда выводит диапазоны, когда компьютер был отключён. Чтобы узнать время перезагрузки (если вам важно отделить эти случаи от включения), то вы можете проанализировать эти данные и данные от предыдущей команды, чтобы получить то, что вам нужно.
Последнее выключение
Как и с перезагрузками, если данных слишком много, то вы можете передать вывод по конвейеру команде head для получения только последнего времени отключения. Конечно, можно указывать разные опции, например, -3 для вывода трёх последний периодов простоя.
Время работы — аптайм (Uptime)
Наконец если вам нужно узнать, как долго ваш компьютер работает, вы можете использовать команду uptime, чтобы получить эту информацию. Дополните её с флагом -p, чтобы вывод был намного более читаемым. Вы получите значение в днях, часах и минутах, которое ваш компьютер включён начиная с последней загрузки.
Надеюсь эти команды помогут решить то, что вы хотите узнать о жизни вашей системы, когда вас нет рядом, о неожиданных перезагрузках и выключениях. Если в проблему вовлечены другие программы, то вы можете проверить определённые файлы журналов в «/var/log».
Причина перезагрузки?
У меня Fedora Core 21 (RFremix, KDE). Сегодня комп неожиданно ребутнулся, буквально пол часа назад. После этого новой сессии не начинал, остановился на текущей. Хочу причину перезагрузки узнать. Вдруг она вообще удалённая была и мой комп порутан?
Знатоков федоры в тред зовем!
Саst 
erzent
«Core» она была до 6 версии, далее и сейчас просто Fedora.
Судя по твоему описанию, скорей всего, ты кнопку резет нажал
у меня юбанта иногда паникует, чё-то там про своп и дрм пишет
в выводе по этой команде нет достаточной инфы
Сегодня комп неожиданно ребутнулся
напряжение упало ниже
так нет же, у меня ноут на батарейке, да и к сети подключен постоянно. эта сволочь хоть и проявила себя гораздо производительней и работает гораздо оптимальней венды, но батарейку жрёт, что просто пипец, так что я с зарядки не снимаю.
Linux version 3.11.10-301.fc20.x86_64 (mockbuild@bkernel01.phx2.f
fc20 написано? я систему до 21 сходу обновил, да и обновки не забываю накатывать, ядро несколько раз уже обновлялось.
но батарейку жрёт, что просто пипец
Нвидиа иль радион очень готовы для десктопа.
Я кстати не прав был, не всю инфу по выводу команды дал. Но лог большой очень уж вышел, фпаст не захотел его есть. Оставил тут: https://www.sendspace.com/file/cqhih1
мар 21 20:05:33 localhost.localdomain systemd-logind[768]: Power key pressed.
мар 21 20:05:33 localhost.localdomain systemd-logind[768]: Powering Off.
мар 21 20:05:33 localhost.localdomain systemd-logind[768]: System is powering down.
я вообще не понимаю где ты это ядро взял, у меня уже 3.19
ты и сейчас не всю, а только февраль
я вообще не понимаю где ты это ядро взял, у меня уже 3.19
я глаза разлепил, оказалось и у меня такое, не туда я посмотрел.
ты и сейчас не всю, а только февраль
Повторил операцию, теперь инфа должна быть в полном обьёме: https://www.sendspace.com/file/kik25m
Батарейку она почему-то жрёт в дуалбуте с Windows, а когда на ноутбуке только Linux, то очень даже экономична.
Батарейку она почему-то жрёт в дуалбуте с Windows, а когда на ноутбуке только Linux, то очень даже экономична.
Пять шагов к спасению Linux-сервера, который рухнул
Мне доводилось видеть множество Linux-серверов, которые, без единой перезагрузки, работали годами, в режиме 24×7. Но ни один компьютер не застрахован от неожиданностей, к которым могут вести «железные», программные и сетевые сбои. Даже самый надёжный сервер может однажды отказать. Что делать? Сегодня вы узнаете о том, что стоит предпринять в первую очередь для того, чтобы выяснить причину проблемы и вернуть машину в строй.
Поиск и устранение неполадок: раньше и теперь
Когда, в 1980-х, я начал работать системным администратором Unix — задолго до того, как Линус Торвальдс загорелся идеей Linux — если с сервером было что-то не так, это была реальная засада. Тогда было сравнительно мало инструментов для поиска проблем, поэтому для того, чтобы сбойный сервер снова заработал, могло понадобиться много времени.
Теперь всё совсем не так, как раньше. Как-то один системный администратор вполне серьёзно сказал мне, говоря о проблемном сервере: «Я его уничтожил и поднял новый».
В былые времена такое звучало бы дико, но сегодня, когда ИТ-инфраструктуры строят на основе виртуальных машин и контейнеров… В конце концов, развёртывание новых серверов по мере необходимости — это обычное дело в любой облачной среде.
Сюда надо добавить инструменты DevOps, такие, как Chef и Puppet, используя которые легче создать новый сервер, чем диагностировать и «чинить» старый. А если говорить о таких высокоуровневых средствах, как Docker Swarm, Mesosphere и Kubernetes, то благодаря им работоспособность отказавшего сервера будет автоматически восстановлена до того, как администратор узнает о проблеме.
Данная концепция стала настолько распространённой, что ей дали название — бессерверные вычисления. Среди платформ, которые предоставляют подобные возможности — AWS Lambda, Iron.io, Google Cloud Functions.
Благодаря такому подходу облачный сервис отвечает за администрирование серверов, решает вопросы масштабирования и массу других задач для того, чтобы предоставить клиенту вычислительные мощности, необходимые для запуска его приложений.
Бессерверные вычисления, виртуальные машины, контейнеры — все эти уровни абстракции скрывают реальные серверы от пользователей, и, в некоторой степени, от системных администраторов. Однако, в основе всего этого — физическое аппаратное обеспечение и операционные системы. И, если что-то на данном уровне вдруг разладится, кто-то должен привести всё в порядок. Именно поэтому то, о чём мы сегодня говорим, никогда не потеряет актуальности.
Помню разговор с одним системным оператором. Вот что он говорил о том, как надо поступать после сбоя: «Переустановка сервера — это путь вникуда. Так не понять — что стало с машиной, и как не допустить такого в будущем. Ни один сносный администратор так не поступает». Я с этим согласен. До тех пор, пока не обнаружен первоисточник проблемы, её нельзя считать решённой.
Итак, перед нами сервер, который дал сбой, или мы, по крайней мере, подозреваем, что источник неприятностей именно в нём. Предлагаю вместе пройти пять шагов, с которых стоит начинать поиск и решение проблем.
Шаг первый. Проверка аппаратного обеспечения
В первую очередь — проверьте железо. Я знаю, что звучит это тривиально и несовременно, но, всё равно — сделайте это. Встаньте с кресла, подойдите к серверной стойке и удостоверьтесь в том, что сервер правильно подключён ко всему, необходимому для его нормальной работы.
Я и сосчитать не смогу, сколько раз поиски причины проблемы приводили к кабельным соединениям. Один взгляд на светодиоды — и становится ясно, что Ethernet-кабель выдернут, или питание сервера отключено.
Конечно, если всё выглядит более-менее прилично, можно обойтись без визита к серверу и проверить состояние Ethernet-соединения такой командой:
Если её ответ можно трактовать, как «да», это значит, что исследуемый интерфейс способен обмениваться данными по сети.
Однако, не пренебрегайте возможностью лично осмотреть устройство. Это поможет, например, узнать, что кто-то выдернул какой-нибудь важный кабель и обесточил таким образом сервер или всю стойку. Да, это до смешного просто, но удивительно — как часто причина отказа системы именно в этом.
Ещё одну распространённую аппаратную проблему невооружённым взглядом не распознать. Так, сбойная память является причиной всевозможных проблем.
Виртуальные машины и контейнеры могут скрывать эти проблемы, но если вы столкнулись с закономерным появлением отказов, связанных с конкретным физическим выделенным сервером, проверьте его память.
Для того, чтобы увидеть, что BIOS/UEFI сообщают об аппаратном обеспечении компьютера, включая память, используйте команду dmidecode:
Даже если всё тут выглядит нормально, на самом деле это может быть и не так. Дело в том, что данные SMBIOS не всегда точны. Поэтому, если после dmidecode память всё ещё остаётся под подозрением — пришло время воспользоваться Memtest86. Это отличная программа для проверки памяти, но работает она медленно. Если вы запустите её на сервере, не рассчитывайте на возможность использовать эту машину для чего-нибудь другого до завершения проверки.
Если вы сталкиваетесь со множеством проблем с памятью — я видел такое в местах, отличающихся нестабильным электропитанием — нужно загрузить модуль ядра Linux edac_core. Этот модуль постоянно проверяет память в поиске сбойных участков. Для того, чтобы загрузить этот модуль, воспользуйтесь такой командой:
Подождите какое-то время и посмотрите, удастся ли что-нибудь увидеть, выполнив такую команду:
Эта команда даст вам сводку о числе ошибок, разбитых по модулям памяти (показатели, название которых начинается с csrow ). Эти сведения, если сопоставить их с с данными dmidecode о каналах памяти, слотах и заводских номерах компонентов, помогут выявить сбойную планку памяти.
Шаг второй. Поиск истинного источника проблемы
Итак, сервер стал странно себя вести, но дым из него ещё пока не идёт. В сервере ли дело? Прежде чем вы попытаетесь решить возникшую проблему, сначала нужно точно определить её источник. Скажем, если пользователи жалуются на странности с серверным приложением, сначала проверьте, что причина проблемы — не в сбоях на клиенте.
Например, друг однажды рассказал мне, как его пользователи сообщили о том, что не могут работать с IBM Tivoli Storage Manager. Сначала, конечно, казалось, что виновен во всём сервер. Но в итоге администратор выяснил, что проблема вообще не была связана с серверной частью. Причиной был неудачный патч Windows-клиента 3076895. Но то, как сбоило это обновление безопасности, делало происходящее похожим на проблему серверной стороны.
Кроме того, нужно понять, является ли причиной проблемы сам сервер, или серверное приложение. Например, серверная программа может работать кое как, а железо оказывается в полном порядке.
Для начала — самое очевидное. Работает ли приложение? Есть множество способов проверить это. Вот два моих любимых:
Если оказалось, что, например, веб-сервер Apache не работает, запустить его можно такой командой:
Если в двух словах, то прежде чем диагностировать сервер и искать причину проблему, узнайте — сервер ли виноват, или что-то другое. Только тогда, когда вы поймёте, где именно находится источник сбоя, вы сможете задавать правильные вопросы и переходить к дальнейшему анализу того, что произошло.
Это можно сравнить с неожиданной остановкой автомобиля. Вы знаете, что машина дальше не едет, но, прежде чем тащить её в сервис, хорошо бы проверить, есть ли бензин в баке.
Шаг третий. Использование команды top
Шаг четвёртый. Проверка дискового пространства
Даже сегодня, когда в кармане можно носить терабайты информации, на сервере, совершенно незаметно, может кончиться дисковое пространство. Когда такое происходит — можно увидеть весьма странные вещи.
Разобраться с дисковым пространством нам поможет старая добрая команда df, имя которой является сокращением от «disk filesystem». С её помощью можно получить сводку по свободному и использованному месту на диске.
Обычно df используют двумя способами.
Если что-то кажется вам странным, можно копнуть глубже, воспользовавшись командой Iostat. Она является частью sysstat — продвинутого набора инструментов для мониторинга системы. Она выводит сведения о процессоре, а также данные о подсистеме ввода-вывода для блочных устройств хранения данных, для разделов и сетевых файловых систем.
Вероятно, самый полезный способ вызова этой команды выглядит так:
Такая команда выводит сведения об объёме прочитанных и записанных данных для устройства. Кроме того, она покажет среднее время операций ввода-вывода в миллисекундах. Чем больше это значение — тем вероятнее то, что накопитель перегружен запросами, или перед нами — аппаратная проблема. Что именно? Тут можно воспользоваться утилитой top для того, чтобы выяснить, нагружает ли сервер MySQL (или какая-нибудь ещё работающая на нём СУБД). Если подобных приложений найти не удалось, значит есть вероятность, что с диском что-то не так.
Работая с утилитами для проверки дисков, обращайте внимание, что именно вы анализируете.
Например, нагрузка в 100% на логический диск, который представляет собой несколько физических дисков, может означать лишь то, что система постоянно обрабатывает какие-то операции ввода-вывода. Значение имеет то, что именно происходит на физических дисках. Поэтому, если вы анализируете логический диск, помните, что дисковые утилиты не дадут полезной информации.
Шаг пятый. Проверка логов
Для новичков в Linux лог-файлы могут выглядеть как ужасная мешанина. Это — текстовые файлы, в которые записываются сведения о том, чем занимаются операционная система и приложения. Есть два вида записей. Одни записи — это то, что происходит в системе или в программе, например — каждая транзакция или перемещение данных. Вторые — сообщения об ошибках. В лог-файлах может содержаться и то, и другое. Эти файлы могут быть просто огромными.
Данные в файлах журналов обычно выглядят довольно таинственно, но вам всё равно придётся с ними разобраться. Вот, например, хорошее введение в эту тему от Digital Ocean.
Есть множество инструментов, которые помогут вам проверить логи. Например — dmesg. Эта утилита выводит сообщения ядра. Обычно их очень и очень много, поэтому используйте следующий простой сценарий командной строки для того, чтобы просмотреть 10 последних записей:
Вот ещё один удобный сценарий командной строки:
Он сканирует логи и показывает возможные проблемы.
Бывает полезно настроить journald так, чтобы он сохранял логи после перезагрузки системы. Сделать это можно, воспользовавшись такой командой:
Самый распространённый способ работать с этими журналами — такая команда:
Она покажет все записи журналов после последней перезагрузки. Если система была перезагружена, посмотреть, что было до этого, можно с помощью такой команды:
Мне, например, нравится система для управления логами с открытым кодом Graylog. Она собирает, индексирует и анализирует самые разные сведения. В её основе лежат MongoDB для работы с данными и Elasticsearch для поиска по лог-файлам. Graylog упрощает отслеживание состояния сервера. Graylog, если сравнить её со встроенными средствами Linux, проще и удобнее. Кроме того, среди её полезных возможностей можно отметить возможность работы с многими DevOps-системами, такими, как Chef, Puppet и Ansible.
Итоги
Как бы вы ни относились к вашему серверу, возможно, он не попадёт в Книгу Рекордов Гиннеса как тот, который проработал дольше всех. Но стремление сделать сервер как можно более стабильным, добираясь до сути неполадок и исправляя их — достойная цель. Надеемся, то, о чём мы сегодня рассказали, поможет вам достичь этой цели.
Уважаемые читатели! А как вы обычно поступаете с упавшими серверами?
Как узнать причину перезагрузки линукс
Отключение кнопкой пишется в логах, если программный сбой, то не 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 |
| Дата: | 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 | |
| Оценка: |
В общем, после продолжительного штудирования Интернета, нашел, что, такого рода перезагрузки обычно бывают в двух случаях:
— проблемы с питанием
— hardware problems.
Первый случай отрицают в дата-центре, второй чаще всего возникает по двум причинам:
— Плохая память (memtest в руки)
— Перегрев.
Для проверки перегрева надо будет поставить логирование всех параметров — температура процессоров, винчестеров и пр. Пока что из этого и буду исходить.
| | От: | Stanislaw K |
| Дата: | 08.09.15 17:51 | |
| Оценка: |
Здравствуйте, prrt, Вы писали:
SK>>Еще большой вопрос, до какой истины ты хочешь докопаться?
P>Найти причину перезагрузки.
SK>>Забрать с хоста все логи за последний месяц и внимательно читать. Логи хоста хранились только на нем? на удаленный syslog не копировались?
P>Логи не копировались, уже изучены, ничего в них нет.
голый линукс — это ядро. ssh это уже ПО третьих производителей.
SK>>Но вопрос прежний — до какой истины ты хочешь докопаться? Зачем? Какую цель преследуешь?
P>Найти причину перезагрузки.
P>В общем, после продолжительного штудирования Интернета, нашел, что, такого рода перезагрузки обычно бывают в двух случаях:
P>- проблемы с питанием
P>- hardware problems.
P>Первый случай отрицают в дата-центре, второй чаще всего возникает по двум причинам:
P>- Плохая память (memtest в руки)
может быть, но как это возможно на сервере? без отметок в логах? сэкономили на памяти ECC RDRAM? это вообще не сервер а бытовой ПЦ?
P>- Перегрев.
В датацентре перегрев? Это ахтунг еще хуже пропадающего электричества.
snmp мониторинг какую температуру чипсета показывает? smartctl температуру жесткого диска?
P>Для проверки перегрева надо будет поставить логирование всех параметров — температура процессоров, винчестеров и пр. Пока что из этого и буду исходить.