Linux логи при выключении

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Не выключается Linux

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

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

Почему не выключается компьютер Linux?

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

Есть несколько путей решения этой проблемы:

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

А теперь давайте рассмотрим пути решения проблемы.

Как исправить ошибку «не выключается Linux»

Чтобы понять, почему система не может выключиться, нам сначала необходимо посмотреть лог её выключения. И тут у нас тоже есть два пути: либо отключить заставку и выводить лог в реальном времени, либо записывать лог выключения с помощью journalctl.

1. Лог выключения в реальном времени

Первый способ не настолько информативный, но всё же может быть полезным. Для отключения заставки откройте /etc/default/grub и в строке GRUB_CMDLINE_LINUX_DEFAULT замените слова quiet splash на verbose:

Источник

Как посмотреть логи выключения системы?

Добрый день. Садится батарея на ноутбуке в выключенном состоянии, есть подозрение что система не отключается полностью. Можно как-то посмотреть логи после нажания кнопки выключения? Или после консольного power off и т.д.

Может у тебя не выключение, а suspend to ram? Тогда батарея немного расходуется на поддержание работы оперативной памяти.

Может у тебя не выключение, а suspend to ram? Тогда батарея немного расходуется на поддержание работы оперативной памяти.

Возможно. Не поскажешь как это проверить?

У меня такая проблема возникла год назад при переходе на линукс. Это где-то в системе.

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

Никаких индикаторов на ноуте нет чтоб понять выключен он или нет?

Если пизнаков активности ноута обнаружить не удастся — возможно у вас просто батарея деградировала, можете ее снять и проверить что не будет такого же эффекта?

Никаких индикаторов на ноуте нет чтоб понять выключен он или нет?

Все индикаторы (питание и жесткий диск) показывают что ноутбук выключен (не светятся).

Если пизнаков активности ноута обнаружить не удастся — возможно у вас просто батарея деградировала, можете ее снять и проверить что не будет такого же эффекта?

Если просто выключить ноутбук, то за ночь он разрядиться на 10%. Если же при этом снять и обратно поставить батарею, ноутбук сможет пролежать неделю и не потерять заряд. Тобишь полностью походу он не выключается (с батареей всё впорядке). Шарил по настройкам BIOS, там ничего нет (повторюсь, это только на линуксе такое, на винде было норм, но не хочу туда возвращаться, уж больно линуксом доволен).

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

Вообще я слышал про ситуации, когда винда при выключении гасила USB-порты, а онтопик — нет, и благодаря возможности ноута питать порты даже при отключенном питании такое поведение разряжало батарею. Сюда же — wake on lan. В общем, смотрите опции bios на эту тему, а также можно попробовать поискать зацепки при помощи tlp и powertop.

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

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

powertop — он же при включенном пк, как он мне поможет?

Если отключить ноутбук удержанием кнопки включения, ситуация аналогична?

Взять мультиметр и пощупать батарею (подключенную) после выключения, попробовать на переферии найти место куда утекают токи.

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

Если отключить ноутбук удержанием кнопки включения, ситуация аналогична?

Нет, если отключить через кнопку — всё хорошо, батарея за ночь не садится, не теряет 10% как при обычном выключении. — это OS.

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

В таком состоянии она теряет очень и очень мизерный заряд за ночь, такой что индикатор его не покажет! Проблема в OS, мне надоело это объяснять всем, кто твердит что дело в батарее. Как конкретно посмотреть логи выключения, в этой теме так никто и не сказал.

мне надоело это объяснять всем. в этой теме так никто и не сказал

Как тебе скажешь, если ты выключение путаешь с саспендом. 1% в час — норма для спящего режима.

Как тебе скажешь, если ты выключение путаешь с саспендом. 1% в час — норма для спящего режима.

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

Нет, если отключить через кнопку — всё хорошо, батарея за ночь не садится, не теряет 10% как при обычном выключении. — это OS.

Источник

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

В ос 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 и подобное чтоб найти того, кто сервак остановил) или просто сдох из-за пропадания питания. Но все-таки мне интересно какое-нибудь изкоробочное решение.

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

Источник

Использование journalctl для просмотра и анализа логов: подробный гайд

Journalctl — отличный инструмент для анализа логов, обычно один из первых с которым знакомятся начинающие администраторы linux систем. Встроенные возможности ротации, богатые возможности фильтрации и возможность просматривать логи всех systemd unit-сервисов одним инструментом очень удобны и заметно облегчают работу системным администраторам.

Эта статья рассматривает основные возможности утилиты journalctl и различные варианты ее применения. С помощью journalctl можно просматривать логи системы, чтобы решить возникшие проблемы на рабочей станции или сервере использующие дистрибутив linux с демоном инициализации systemd, де-факто уже ставшим стандартом в современных Linux-системах, например: RHEL, CentOS, Fedora, Debian и многих других.

Существует мнение, что systemd не так уж и хорош — он нагружает систему и это все еще предмет для споров на сегодняшний день, но нельзя отрицать, что он предоставляет прекрасный набор инструментов для управления системой и поиска проблем. Представьте, что вам приходится иметь дело с проблемным сервером, который даже не загружается — в таком случае можно загрузиться с live-дистрибутива, смонтировать системный раздел и просмотреть логи systemd, чтобы понять, в чем проблема.

Systemd

Systemd состоит из трех основных компонентов:

• systemd — менеджер системы и сервисов
• systemctl — утилита для просмотра и управление статусом сервисов
• systemd-analyze — предоставляет статистику по процессу загрузки системы, проверяет корректность unit-файлов и так же имеет возможности отладки systemd

Journald

Journald — системный демон журналов systemd. Systemd спроектирован так, чтобы централизованно управлять системными логами от процессов, приложений и т.д. Все такие события обрабатываются демоном journald, он собирает логи со всей системы и сохраняет их в бинарных файлах.

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

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

Файл конфигурации journald

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

Каталог с журналом journald располагается /run/log/journal (в том случае, если не настроено постоянное хранение журналов, но об этом позже).

Файлы хранятся в бинарном формате, поэтому нормально их просмотреть с помощью cat или nano, как привыкли многие администраторы — не получится.

Использование journalctl для просмотра и анализа логов

Основная команда для просмотра:

Она выведет все записи из всех журналов, включая ошибки и предупреждения, начиная с того момента, когда система начала загружаться. Старые записи событий будут наверху, более новые — внизу, вы можете использовать PageUp и PageDown чтобы перемещаться по списку, Enter — чтобы пролистывать журнал построчно и Q — чтобы выйти.

По умолчанию journalctl выводит время событий согласно настроенного в вашей системе часового пояса, также journalctl позволяет просмотреть логи с временем UTC (в этом стандарте времени сохраняются события внутри файлов journald), для этого можно использовать команду:

Фильтрация событий по важности

Система записывает события с различными уровнями важности, какие-то события могут быть предупреждением, которое можно проигнорировать, какие-то могут быть критическими ошибками. Если мы хотим просмотреть только ошибки, игнорируя другие сообщения, введем команду с указанием кода важности:
# journalctl -p 0

Для уровней важности, приняты следующие обозначения:

• 0: emergency (неработоспособность системы)
• 1: alerts (предупреждения, требующие немедленного вмешательства)
• 2: critical (критическое состояние)
• 3: errors (ошибки)
• 4: warning (предупреждения)
• 5: notice (уведомления)
• 6: info (информационные сообщения)
• 7: debug (отладочные сообщения)

Когда вы указываете код важности, journalctl выведет все сообщения с этим кодом и выше. Например если мы укажем опцию -p 2, journalctl покажет все сообщения с уровнями 2, 1 и 0.

Настройка хранения журналов

По умолчанию journald перезаписывает свои журналы логов при каждой перезагрузке, и вызов journalctl выведет журнал логов начиная с текущей загрузки системы.

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

Когда в конфигурационном файле /etc/systemd/journald.conf параметру Storage= задано значение auto) и каталога /var/log/journal/ не существует, журнал будет записываться в /run/log/journal без сохранения между перезагрузками, если /var/log/journal/ существует, журналы будут сохраняться в нем, на постоянной основе, но если каталог будет удален, systemd не пересоздаст его автоматически и вместо этого будет вести журнал снова в /run/systemd/journal без сохранения. Каталог может быть пересоздан в таком случае, если добавить Storage=persistent в journald.conf и перезапустить systemd-journald.service (или перезагрузиться).

Создадим каталог для хранения журналов, установим необходимые атрибуты и перезапустим службу:

Просмотр журналов загрузки

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

Первый номер показывает номер журнала, который можно использовать для просмотра журнала определенной сессии. Второй номер boot ID так же можно использовать для просмотра отдельного журнала.

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

Например, чтобы просмотреть журнал начиная с текущего старта системы, можно использовать команду:

А для того, чтобы просмотреть журнал предыдущей загрузки:

Просмотр журнала за определенный период времени

Journalctl позволяет использовать такие служебные слова как “yesterday” (вчера), “today” (сегодня), “tomorrow” (завтра), или “now” (сейчас).

Поэтому мы можем использовать опцию «—since» (с начала какого периода выводить журнал).

С определенной даты и времени:

С определенной даты и по определенное дату и время:

Со вчерашнего дня:

С 9 утра и до момента, час назад:

Просмотр сообщений ядра

Чтобы просмотреть сообщения от ядра Linux за текущую загрузку, используйте команду с ключом -k:

Просмотр журнала логов для определенного сервиса systemd или приложения

Вы можете отфильтровать логи по определенному сервису systemd. Например, что бы просмотреть логи от NetworkManager, можно использовать следующую команду:

Если нужно найти название сервиса, используйте команду:

Так же можно просмотреть лог приложения, указав его исполняемый файл, например чтобы просмотреть все сообщения от nginx за сегодня, мы можем использовать команду:

Или указав конкретный PID:

Дополнительные опции просмотра

Следить за появлением новых сообщений (аналог tail -f):

Открыть журнал «перемотав» его к последней записи:

Если в каталоге с журналами очень много данных, то фильтрация вывода journalctl может занять некоторое время, процесс можно значительно ускорить с помощью опции —file, указав journalctl только нужный нам журнал, за которым мы хотим следить:

По умолчанию journalctl отсекает части строк, которые не вписываются в экран по ширине, хотя иногда перенос строк может оказаться более предпочтительным. Управление этой возможностью производится посредством переменной окружения SYSTEMD_LESS, в которой содержатся опции, передаваемые в less (программу постраничного просмотра, используемую по умолчанию). По умолчанию переменная имеет значение FRSXMK, если убрать опцию S, строки не будут обрезаться.

Ограничение размера журнала

Если journald настроен что бы сохранять журналы после перезагрузки, то по умолчанию размер журнала ограничен 10% от объема файлового раздела и максимально может занять 4 Гб дискового пространства.

Максимальный объем журнала можно скорректировать, раскомментировав и отредактировав следующий параметр в файле конфигурации journald:

Удаление журналов

Удалить файлы архивных журналов, можно вручную с помощью rm или использовав journalctl.

Удалить журналы, оставив только последние 100 Мб:

Удалить журналы, оставив журналы только за последние 7 дней:

Заключение

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

Источник