Как понять, почему Linux-сервер перезагрузился
Пошаговая диагностика неожиданной перезагрузки Linux: время события, история загрузок, предыдущий журнал ядра, ограничения журналирования и признаки аварийного завершения.
В этой статье
Сервер снова доступен, но причина перезагрузки не исчезает вместе с простоем. До обновлений и новых перезапусков важно зафиксировать время события, границы предыдущей загрузки и последние сообщения ядра. Эта инструкция предназначена для Ubuntu 24.04 LTS с systemd; команды только читают состояние.
Команды сверены с документацией systemd и util-linux 26 сентября 2026 года. Они выполнены в изолированном окружении Ubuntu 24.04.3 LTS. В нём постоянный журнал и история загрузок отсутствовали, поэтому такой результат отдельно разобран ниже; аварийная перезагрузка намеренно не воспроизводилась.
1. Уточните время текущей загрузки
uptime -s
Команда показывает время запуска текущей системы. Сопоставьте его с мониторингом, обращениями и событиями провайдера. Это граница, после которой причины в текущем журнале искать поздно: интерес обычно находится в конце предыдущей загрузки.
2. Посмотрите записи о перезагрузках и выключениях
last -x --time-format iso -n 20
Опция с расширенными событиями добавляет записи перезагрузки и выключения из журнала wtmp, формат ISO упрощает сравнение часовых поясов, а ограничение числа строк защищает от длинного вывода. Запись reboot без предшествующего shutdown может указывать на нештатное завершение, но сама по себе не доказывает причину.
Пустой вывод возможен, если файл истории отсутствует, очищен, не сохраняется в контейнере или начинается позже события. В тестовом окружении команда сообщила только дату начала wtmp и не показала перезагрузок. Это ограничение источника, а не подтверждение, что сервер не перезапускался.
3. Проверьте, видит ли journalctl предыдущие загрузки
journalctl --list-boots --no-pager
Список содержит идентификатор, относительный номер и временные границы каждой сохранённой загрузки. Текущая обычно имеет номер 0, предыдущая — -1. Если есть только текущая загрузка, перейти к старому журналу не получится.
4. Прочитайте предупреждения предыдущей загрузки
journalctl -b -1 -p warning..alert --no-pager
Фильтр выбирает предыдущую загрузку и уровни от warning до alert. Начните с последних сообщений и смотрите контекст времени. Не каждый warning связан с перезагрузкой, а отсутствие предупреждений не исключает потерю питания: система могла не успеть записать причину.
5. Отдельно проверьте сообщения ядра
journalctl -k -b -1 --no-pager
Ищите сообщения о нехватке памяти, зависании, аппаратных ошибках, файловой системе, watchdog и панике ядра. Термин в строке ещё не равен диагнозу: например, сообщение о завершённом восстановлении файловой системы может быть следствием внезапного выключения, а не его причиной.
Наблюдение | Что оно может означать | Что проверить дальше |
|---|---|---|
Корректный shutdown перед reboot | Плановый перезапуск | Кто запустил действие, обновления, автоматика |
Нет конца предыдущего журнала | Потеря питания или несохранённые журналы | Консоль провайдера, питание, постоянство журнала |
Сообщения OOM | Ядро завершало процессы из-за памяти | Графики RAM, swap, владельца памяти |
Watchdog или lockup | Зависание системы или ядра | Версию ядра, оборудование, дамп |
Ошибки диска или ФС | Проблема хранения либо последствие сбоя | SMART у провайдера, консоль, проверку в окно работ |
Если journalctl пишет, что журналов нет
Сначала проверьте наличие каталога /var/log/journal и политику journald. Не создавайте каталог и не меняйте настройки только ради расследования уже прошедшего события: это не вернёт потерянные записи.
ls -ld /var/log/journal
В контейнерах журнал часто не сохраняется или управляется хостом. На VPS часть причин — аппаратный сброс, миграция узла, действие панели — видна только в консоли провайдера. Запросите события для точного интервала и укажите часовой пояс.
Когда остановиться и эскалировать
Перезагрузка повторяется, а в журнале есть ошибки диска, файловой системы, watchdog или паника ядра.
Время загрузки не совпадает с данными панели и мониторинга.
Предыдущий журнал отсутствует на сервере, где по политике он должен быть постоянным.
Перед перезапуском был OOM, но владелец памяти не установлен.
Для продолжения потребуется проверка файловой системы, обновление ядра или изменение конфигурации.
Не начинайте с принудительного завершения процессов, очистки журналов или повторного перезапуска. Сохраните доступные строки, время и идентификатор загрузки. Изменения системы проводят отдельно, с резервной копией, согласованным простоем и способом отката.
The server is back online, but the cause of the reboot does not disappear with the downtime. Before updates and new reboots, it is crucial to record the event time, the boundaries of the previous boot, and the latest kernel messages. This guide is intended for Ubuntu 24.04 LTS with systemd; the commands only read the system state.
Commands were verified against systemd and util-linux documentation as of September 26, 2026. They were executed in an isolated Ubuntu 24.04.3 LTS environment. In that environment, persistent logging and boot history were absent, so this result is analyzed separately below; an emergency reboot was not intentionally reproduced.
1. Clarify the current boot time
uptime -s
The command displays the start time of the current system. Compare it with monitoring data, support tickets, and provider events. This marks the boundary after which causes in the current log are too late to investigate; the interest usually lies at the end of the previous boot.
2. Review reboot and shutdown records
last -x --time-format iso -n 20
The option with extended events adds reboot and shutdown records from the wtmp log, the ISO format simplifies time zone comparison, and the row limit protects against excessively long output. A reboot record without a preceding shutdown may indicate an abnormal termination, but it does not prove the cause on its own.
Empty output is possible if the history file is missing, cleared, not saved in the container, or starts after the event. In the test environment, the command reported only the wtmp start date and showed no reboots. This is a source limitation, not confirmation that the server was not rebooted.
3. Check if journalctl sees previous boots
journalctl --list-boots --no-pager
The list contains the identifier, relative number, and time boundaries for each saved boot. The current boot usually has number 0, the previous one -1. If only the current boot exists, you cannot switch to the old log.
4. Read warnings from the previous boot
journalctl -b -1 -p warning..alert --no-pager
The filter selects the previous boot and log levels from warning to alert. Start with the latest messages and examine the time context. Not every warning is related to a reboot, and the absence of warnings does not rule out power loss: the system may not have had time to record the cause.
5. Check kernel messages separately
journalctl -k -b -1 --no-pager
Look for messages about memory shortage, hangs, hardware errors, file system issues, watchdog events, and kernel panics. A term in a log line is not yet a diagnosis: for example, a message about a completed file system recovery may be a consequence of an unexpected shutdown, not its cause.
Observation | What it may mean | What to check next |
|---|---|---|
Correct shutdown before reboot | Planned restart | Who initiated the action, updates, or automation |
No end of the previous log | Power loss or unsaved logs | Provider console, power, log persistence |
OOM messages | Kernel terminated processes due to memory | RAM, swap, and memory owner graphs |
Watchdog or lockup | System or kernel hang | Kernel version, hardware, and dump |
Disk or file system errors | Storage issue or consequence of a failure | SMART data from the provider, console, and checks during maintenance windows |
If journalctl reports that there are no logs
First, verify the existence of the /var/log/journal directory and the journald policy. Do not create the directory or change settings solely to investigate an event that has already occurred; this will not restore lost records.
ls -ld /var/log/journal
In containers, logs are often not persisted or are managed by the host. On a VPS, some causes—hardware reset, node migration, or panel action—are visible only in the provider console. Request events for the exact time interval and specify the time zone.
When to stop and escalate
The reboot repeats, and the log contains disk errors, file system errors, watchdog events, or a kernel panic.
The boot time does not match the data from the control panel and monitoring.
The previous log is missing from the server where it should be retained according to policy.
An OOM occurred before the restart, but the memory owner is not set.
Continuing will require a file system check, a kernel update, or a configuration change.
Do not start by forcibly terminating processes, clearing logs, or restarting. Save available log lines, timestamps, and boot identifiers. System changes must be performed separately, with a backup, a coordinated downtime window, and a rollback procedure.
Обсуждение 0
Делись опытом и задавай вопросы. Комментарии без ссылок появляются после проверки редактором.
Пока никто не написал. Начни обсуждение.