Сервер сам перезагрузился: как понять почему

MAATRIX

Мониторинг прислал уведомление, аптайм обнулился, сервисы поднялись заново — сервер перезагрузился сам, без вашей команды. Тревожно, потому что причина неочевидна, а значит, может повториться. Хорошая новость: система почти всегда оставляет следы, по которым понятно, что случилось. Ниже пошаговое решение проблемы — как по логам определить, почему сервер сам перезагрузился: нехватка памяти, паника ядра, сбой питания или действия провайдера.

Первый шаг: смотрим время и факт перезагрузки

Сначала зафиксируем факты: когда именно перезагрузился сервер и сколько таких событий было. Это отсекает догадки и задаёт точку отсчёта для поиска в логах. Команды uptime, last reboot и who -b дают время последней загрузки и историю:

# сколько работает сейчас
uptime
# история перезагрузок и выключений
last -x reboot shutdown | head
# точное время последней загрузки
who -b

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

Различаем чистую перезагрузку и жёсткое падение

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

# журнал предыдущей загрузки целиком
journalctl -b -1 --no-pager | tail -60
# сообщения о выключении/старте
journalctl -b -1 -e | grep -iE 'shutdown|reboot|power|kernel'

Если перед обрывом логов вы видите записи об остановке сервисов — перезагрузку кто-то инициировал (провайдер, задание, обновление ядра). Если логи просто оборвались без единого слова о завершении — это жёсткое падение: паника ядра, OOM, потеря питания или сброс со стороны гипервизора. Определив тип, вы сразу сужаете список причин вдвое.

Проверяем нехватку памяти (OOM)

Частая причина внезапной нестабильности на VPS — исчерпание оперативной памяти. Когда память заканчивается, ядро запускает OOM-killer, который убивает процессы, а в тяжёлых случаях система теряет критичный процесс и уходит в перезагрузку. Следы OOM остаются в журнале ядра:

# искать факты срабатывания OOM-killer
journalctl -k -b -1 | grep -i 'out of memory'
dmesg | grep -iE 'killed process|oom'
# текущее состояние памяти и свопа
free -h

Если находите строки Out of memory: Killed process, причина ясна: серверу не хватило памяти. Это типично, когда на скромном тарифе крутится прожорливое приложение, база с большим кэшем или всё сразу, а свопа нет. Лечится это либо оптимизацией потребления, либо добавлением swap как страховки, либо переходом на тариф с большим объёмом RAM. Отсутствие свопа делает нехватку памяти особенно резкой — системе некуда отступить, и она падает вместо того, чтобы притормозить.

Паника ядра и сбои драйверов

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

# признаки паники ядра
journalctl -k -b -1 | grep -iE 'panic|bug|oops|call trace'

Если такие записи есть, обратите внимание, какой модуль или драйвер упоминается в трассировке, — это указывает на источник. Паники после обновления ядра намекают на несовместимость: помогает откат на предыдущую версию ядра из меню загрузки. На выделенном железе повторяющиеся паники без явной программной причины могут указывать на аппаратный дефект — сбойную планку памяти, перегрев. На VPS такие вещи вне вашей зоны, и если паники системные и регулярные, стоит поднять вопрос с провайдером.

Когда причина на стороне провайдера

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

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

Профилактика: ловим причину заранее

Чтобы не расследовать каждую перезагрузку задним числом, настройте наблюдение заранее. Мониторинг памяти и нагрузки с уведомлениями предупредит о подступающем OOM до того, как сервер упадёт. Настроенный swap даст системе запас и превратит резкое падение в терпимое замедление. Сохранение логов на внешний сервер спасёт причину падения, если локальный журнал обрывается.

• Настройте мониторинг RAM, диска и нагрузки с алертами.
• Держите swap хотя бы на пару гигабайт как страховку от OOM.
• Ограничивайте память прожорливых сервисов, чтобы OOM-killer не бил вслепую.
• После обновления ядра будьте готовы откатиться, если пойдут паники.
• Отправляйте важные логи наружу, чтобы не потерять их при падении.

Стабильность начинается с надёжной площадки и достаточных ресурсов. У MAATRIX VPS и выделенные серверы в локациях RU, US и UK работают на проверенном железе, с оплатой из России картой или криптой, а мониторинг и запас по памяти под вашу нагрузку убирают самую частую причину внезапных ребутов. Когда ресурсов хватает, а хост стабилен, аптайм измеряется месяцами, а не днями.

Частые вопросы