How to Determine Why a Linux Server Rebooted

Сервер снова доступен, но причина перезагрузки не исчезает вместе с простоем. До обновлений и новых перезапусков важно зафиксировать время события, границы предыдущей загрузки и последние сообщения ядра. Эта инструкция предназначена для Ubuntu 24.04 LTS с systemd; команды только читают состояние.

Команды сверены с документацией systemd и util-linux 26 сентября 2026 года. Они выполнены в изолированном окружении Ubuntu 24.04.3 LTS. В нём постоянный журнал и история загрузок отсутствовали, поэтому такой результат отдельно разобран ниже; аварийная перезагрузка намеренно не воспроизводилась.

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

Опция с расширенными событиями добавляет записи перезагрузки и выключения из журнала wtmp, формат ISO упрощает сравнение часовых поясов, а ограничение числа строк защищает от длинного вывода. Запись reboot без предшествующего shutdown может указывать на нештатное завершение, но сама по себе не доказывает причину.

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

Список содержит идентификатор, относительный номер и временные границы каждой сохранённой загрузки. Текущая обычно имеет номер 0, предыдущая — -1. Если есть только текущая загрузка, перейти к старому журналу не получится.

Фильтр выбирает предыдущую загрузку и уровни от warning до alert. Начните с последних сообщений и смотрите контекст времени. Не каждый warning связан с перезагрузкой, а отсутствие предупреждений не исключает потерю питания: система могла не успеть записать причину.

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

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

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

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.

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.

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.

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.

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.

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.

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.

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.