Перезагрузка растянулась на час: что сервер делал всё это время

MAATRIX

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

Первая паника: «сервер не включается»

Обычная перезагрузка Linux-сервера — это секунды, максимум минута: ядро выгружается, железо/гипервизор перезапускает виртуальную машину, ядро грузится заново, systemd поднимает юниты, сеть встаёт, SSH отвечает. Когда вместо минуты проходит 15, 30, 60 минут — это ощущается как авария, и первый инстинкт большинства — жать power reset ещё раз или писать в поддержку «сервер лёг».

Но здесь важно разделить два принципиально разных состояния:

• Сервер не отвечает на ping и не откликается на порт управления (IPMI/VNC/serial console недоступны). Это действительно похоже на аппаратную проблему — здесь время реакции критично, и стоит сразу открывать консоль через панель провайдера.
• Сервер не отвечает на SSH, но консоль через IPMI/VNC показывает живой экран с логами загрузки. Вот это и есть «растянутая перезагрузка» — процесс идёт, просто завис на конкретном шаге. Паниковать рано: нужно прочитать, что написано на экране.

Разница между этими двумя случаями — как раз то, ради чего стоит держать под рукой доступ к консоли, а не только SSH. Если у вас его нет или вы не уверены, как подключиться, — это отдельная тема, разобранная в статье про IPMI и удалённое управление железом. Дальше в этом разборе предполагаем, что консоль у вас есть и на экране что-то написано — вопрос в том, что именно.

Долгий fsck после нечистого выключения

Самая частая причина «сервер завис при загрузке» — это fsck (file system check), автоматическая проверка файловой системы. Ядро Linux помечает файловую систему как «грязную» (dirty), если предыдущее выключение прошло не штатно: аварийный power reset, зависание, kernel panic, обрыв питания в дата-центре. При следующей загрузке init-система видит этот флаг и запускает полную проверку диска, прежде чем смонтировать раздел.

На большом диске (несколько терабайт) с ext4 или xfs такая проверка может занимать от нескольких минут до десятков минут — это зависит от объёма занятого места, количества файлов (inode) и скорости самого диска. На консоли в этот момент обычно видно что-то вроде:

Checking file system on /dev/sda1
fsck from util-linux 2.38
/dev/sda1: recovering journal
/dev/sda1: clean, 1234567/61054976 files, 987654321/244190464 blocks

или, если журналирования не хватило и требуется полная проверка:

/dev/sda1 contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure

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

Отличить «просто долго» от «реально зависло» помогает время: если счётчик blocks/inodes не двигается вообще несколько минут при активности диска (индикатор I/O) — это подозрительно и может говорить о проблеме с самим накопителем, а не о размере данных.

systemd честно ждёт зависимость до таймаута

Второй по частоте виновник — не диск, а systemd. Современные дистрибутивы грузятся через systemd, который поднимает юниты по зависимостям: сеть, диск, DNS, внешние сервисы. Если юнит объявлен зависимым от другого сервиса (например, от сети или от смонтированного NFS-раздела), а этот другой сервис не отвечает — systemd не падает сразу, он ждёт до таймаута, прописанного в юните (по умолчанию часто 90 секунд, но для сетевых операций и монтирований бывает и 5, и 10 минут).

Типичные кандидаты, которые могут держать загрузку надолго:

• network-online.target — если сервер ждёт полной сетевой готовности (например, DHCP-ответа), а сеть недоступна;
• монтирование сетевого хранилища из /etc/fstab (NFS, CIFS) — если удалённый сервер недоступен, монтирование виснет на таймауте (иногда это _netdev без nofail, тогда загрузка стоит наглухо);
• systemd-networkd-wait-online — специально создан для ожидания сети и может стоять по умолчанию с большим таймаутом;
• юниты, которые ждут внешний API или БД при старте приложения.

На консоли в этот момент обычно видно характерную строку с указанием, сколько ещё ждать:

[  *** ] A start job is running for /mnt/backup (4min 12s / 10min)

Это самый информативный индикатор из всех — systemd прямо говорит, какой юнит виснет и сколько у него осталось до таймаута. Если вы видите такую строку — вы уже знаете виновника, осталось решить, ждать ли оставшиеся минуты или вмешаться. Подробнее про то, как устроен порядок загрузки и зависимости юнитов, — в статье как работает systemd при загрузке.

Долгая пересборка или проверка RAID-массива

Если на сервере есть программный (mdadm) или аппаратный RAID, третий частый виновник — ресинхронизация или проверка массива. Она запускается в нескольких случаях: массив был собран не полностью на момент выключения, один из дисков был заменён, произошёл нечистый рестарт во время активной записи, либо это плановая периодическая проверка (check/scrub), которую многие дистрибутивы запускают по расписанию (например, раз в месяц по cron).

Для программного RAID состояние ресинка можно увидеть даже удалённо (если сеть уже поднялась) через:

cat /proc/mdstat

md0 : active raid6 sdc1[2] sdb1[1] sda1[0] sdd1[3]
      7813775360 blocks super 1.2 level 6, 512k chunk, algorithm 2 [4/4] [UUUU]
      [=======>.............]  resync = 38.2% (1494839296/3906887680) finish=210.4min speed=89234K/sec

Ключевая строка — finish=210.4min — это оценка, сколько ещё осталось. Ресинк не блокирует загрузку системы полностью (массив обычно уже доступен на чтение/запись в degraded-режиме), но если на массиве лежит корневая файловая система или он критичен для старта сервисов, часть загрузки может ждать его готовности, а производительность диска на время ресинка заметно просядет.

Для аппаратного RAID-контроллера картина похожая, но проверяется она обычно через утилиту вендора (storcli, megacli, hpacucli/ssacli в зависимости от контроллера) уже после того, как ОС загрузится — во время самой загрузки прогресс инициализации массива часто виден прямо в BIOS/UEFI-экране контроллера, до передачи управления загрузчику ОС. Как устроена логика деградации и восстановления массива при отказе диска, разобрано в статье как работает RAID при отказе диска.

Как диагностировать: задним числом и в моменте

Диагностика раздваивается на два режима — то, что можно сделать только после того, как сервер всё-таки загрузился, и то, что доступно прямо сейчас, пока экран висит.

Постфактум, когда SSH снова отвечает, лучший инструмент — systemd-analyze. Он показывает, сколько реально заняла загрузка и какой юнит был на критическом пути:

systemd-analyze

Startup finished in 8.912s (kernel) + 52min 14.331s (userspace) = 52min 23.243s
graphical.target reached after 52min 14.108s in userspace

Уже здесь видно, что проблема не в ядре (8.9 секунд — норма), а в userspace, то есть в systemd-юнитах. Дальше — детализация:

systemd-analyze blame

Эта команда выводит список юнитов, отсортированный по времени запуска — виновник почти всегда в топе списка с большим отрывом от остальных:

52min 1.203s network-online.target
       2.341s docker.service
       1.892s postgresql.service

А systemd-analyze critical-chain покажет саму цепочку зависимостей — кто кого ждал и в каком порядке, что полезно, если виновников несколько и они связаны друг с другом:

systemd-analyze critical-chain

В моменте, пока сервер висит и SSH недоступен, единственный источник данных — вывод на консоли (serial console, IPMI SOL, VNC-консоль в панели провайдера, или консоль гипервизора, если это VPS). Здесь нет команд, которые можно выполнить, — только чтение того, что уже написано на экране. Смотрите на последнюю строку и на то, меняется ли она:

• если последняя строка — про fsck и цифры (проценты, номера блоков) двигаются — ждите, это диск;
• если видна строка A start job is running for ... с таймером — это конкретный systemd-юнит, и таймер сам скажет, сколько ждать;
• если экран замер на одной строке без изменений в течение нескольких минут при этом диск (по индикатору активности, если он виден) не работает — это уже больше похоже на реальное зависание, а не на длительную операцию.

Экстренное вмешательство: когда и как прерывать

Если по консоли явно видно, на каком юните стоит загрузка (та самая строка A start job is running for X), и вы понимаете, что этот юнит вам сейчас не критичен (например, это монтирование резервного NFS-хранилища, которого сейчас просто нет в сети) — можно прервать ожидание вручную прямо в этой консоли, не дожидаясь таймаута:

Ctrl+C

на многих системах именно это сочетание в момент показа A start job is running прерывает ожидание конкретного юнита и позволяет загрузке продолжиться без него (зависимые юниты, если они не строго обязательны, будут пропущены или помечены как failed, а не остановят всю загрузку).

Важные оговорки:

• Если юнит критичен (например, это точка монтирования, без которой не поднимется корневой раздел или база данных) — прерывание не поможет, система всё равно не запустится корректно, просто ошибка проявится раньше.
• Если ждёт именно fsck — прерывать его силовым способом не стоит вообще: это тот случай, когда лучше подождать до конца, чем получить повреждённую файловую систему и начинать всё заново.
• Если консоль вообще не реагирует ни на что (даже курсор не мигает) — это уже не «долгая операция», а реальное зависание ядра или гипервизора, и здесь остаётся только hard reset через панель управления.

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

Профилактика: как не попасть в эту ситуацию снова

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

Выключайте сервер штатно, а не через силовой ресет. Команда shutdown -h now или reboot даёт системе время корректно размонтировать файловые системы и сбросить журнал на диск — именно это снимает флаг «грязной» файловой системы и избавляет от полного fsck при следующем старте. Силовой ресет (аппаратный power cycle, «выключить и включить» в панели гипервизора без штатного шатдауна) почти всегда оставляет файловую систему в dirty-состоянии.

Проверьте таймауты systemd-юнитов, которые реально критичны для вашей нагрузки. Если у вас есть монтирование сетевого ресурса в /etc/fstab, добавьте опцию nofail, чтобы его недоступность не блокировала всю загрузку:

192.168.1.10:/backup /mnt/backup nfs defaults,nofail,_netdev 0 0

Для юнитов с собственным TimeoutStartSec — оцените, действительно ли вам нужны 5-10 минут ожидания, или для вашего сценария разумнее сократить таймаут до минуты, чтобы быстрее получить явную ошибку вместо тихого зависания.

Настройте периодические проверки RAID и диска так, чтобы они не совпадали с моментом перезагрузки. Плановый check/scrub массива лучше запускать по расписанию в наименее нагруженное время, а не полагаться на то, что он не пересечётся со внезапной перезагрузкой.

Держите под рукой доступ к консоли, а не только SSH. Без него любая долгая загрузка выглядит как «сервер умер», хотя на деле это просто один медленный этап — а с консолью вы за 10 секунд видите точную причину и понимаете, ждать пять минут или пять часов.

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

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