Сервер перезагружается после обновления, экран гаснет, потом появляется строка с таймером и сообщением о выполняемом задании запуска. Счётчик отсчитывает полторы минуты, потом ещё, и загрузка буксует на месте. Знакомая сцена: система чего-то ждёт, а чего именно, не говорит. Причины у ожидания всегда конкретные, и у менеджера загрузки есть инструменты, чтобы назвать виновника по имени. Статья разбирает смысл сообщения, вход в аварийный режим, диагностику в нём, поиск зависшего юнита и типовых виновников с лечением.
Смысл сообщения о задании и логика ожидания при загрузке
Менеджер загрузки собирает запуск системы из заданий: каждый юнит это задание, и у заданий есть зависимости. Пока задание не завершено, зависящие от него ждут, а на экране честно печатается, чего именно ждут и сколько времени это длится. Сообщение с таймером означает: какое-то задание не завершается, и загрузка стоит перед ним в очереди.
Каждое задание имеет таймаут запуска. По истечении лимита менеджер либо продолжает загрузку, пометив задание проваленным, либо уходит в аварийный режим, в зависимости от критичности юнита. Первая ветка объясняет серверы, которые грузятся долго, но доезжают: полторы минуты ожидания на каждый зависший юнит, и если их три, завтрак затягивается.
Критично важные юниты при провале отправляют систему в аварийный режим самостоятельно: на экране появляется приглашение оболочки, а не очередь заданий. И ожидание на экране, и мгновенный аварийный режим это два лица одной картины, и разбор обеих ведётся одними инструментами.
Первый вывод для спокойствия: сведения при этом сценарии почти всегда целы. Загрузка буксует на ожиданиях, а не на разрушении, и тревога неуместна раньше конца диагностики. Второй вывод: экран с сообщением это подсказка, в нём напечатано имя ожидающего юнита или службы, и прочитать его до перезагрузки стоит внимательно.
Вход в аварийный режим через параметры загрузки
Если система ждёт на экране, вход в оболочку подсказан самой загрузкой: внизу экрана обычно перечислены клавиши, нажатие которых прерывает ожидание. Если экран ушёл в аварийный режим сам, оболочка уже перед вами. Остаётся сценарий, когда загрузка крутится по кругу или экран ничего не предлагает: тогда аварийный режим включается через параметры загрузчика.
Приём стандартный: в меню загрузчика выбирается нужная запись, открывается правка, к строке параметров ядра дописывается параметр аварийного режима, и загрузка продолжается с ним. Менеджер не тянет зависимости и выдаёт минимальную оболочку без лишнего. Вариант режима спасения чуть мягче: он поднимает чуть больше служб и подходит, когда хочется и сеть, и журналы сразу.
Разница между режимами краткая: аварийный режим это корневая файловая система в режиме чтения и почти ничего больше; режим спасения добавляет монтирование по привычным точкам и базовые службы. Для диагностики загрузки чаще достаточно аварийного, а опытные администраторы пробуют спасательный как более удобный и переходят к аварийному при его отказе.
Доступ в аварийную оболочку требует пароль администратора, и это правильная защита: минимальная система остаётся системой с полными правами для того, кто вошёл. Аварийная оболочка не принимает подсказок, но принимает все команды, и следующая часть статьи это именно они.
Работа в аварийной оболочке от перемонтирования до журнала
Аварийная оболочка встречает корнем в режиме чтения, и первый шаг всегда один: перемонтировать корень для записи, иначе ни правка конфигурации, ни сохранение протокола не заработают:
mount -o remount,rw /Второй шаг это ориентация: которая сейчас загрузка, жива ли сеть, куда пишутся журналы. В минимальной системе журналы могут лежать только в памяти, и утилита чтения журнала работает и там: выбираются записи текущей загрузки, и хвост журнала читается как сводка того, что менеджер делал перед остановкой.
Третий шаг это список заданий, и он главный: команда показывает все задания, которые менеджер считал незавершёнными на момент входа в оболочку. В списке видны висящие задания с временем ожидания, и имя виновника стоит прямо в списке. Один этот экран отвечает на вопрос, из-за чего загрузка стояла, лучше любого пересказа.
systemctl list-jobs
journalctl -b --no-pager | tail -50Четвёртый шаг это статус конкретного юнита: по имени из списка запрашивается состояние, последние строки журнала юнита и время ожидания. Статус честно показывает, чего ждёт юнит: устройство, сетевую готовность, удалённый ресурс, и подсказка в статусе обычно достаточно прямая, чтобы перейти к причинам.
Аварийная оболочка это рабочее место без удобств: редактор вызывается тем, что установлен, сеть поднимается вручную при необходимости, протокол пишется в файл, который потом заберёте. Неудобство временно, а привычка спокойно работать в аварийной оболочке стоит того, чтобы завести её заранее на учебном сервере.
Поиск виноватого юнита списком задач и журналом загрузки
Список заданий отвечает на вопрос, кто висит, но не всегда на вопрос, почему висит. Для второго журналы: записи текущей загрузки показывают цепочку событий, и читать стоит от конца, снизу вверх. Последние записи перед ожиданием это всегда контекст: юнит запустился, дождался таймаута, либо молчит в ожидании внешнего.
Утилита анализа загрузки дополняет картину списком длительностей: каждая служба получает своё время запуска, и список по убыванию честно показывает, кто съедает минуты. Утилита строит и цепочку критического пути загрузки, и в цепочке видно, на каком звене загрузка упирается в ожидание. Для повторяющихся медленных загрузок, не доходящих до сообщений на экране, это основной инструмент.
Сравнение загрузок добавляет дедукции: журнал прошлой загрузки, когда всё работало, показывает разницу окружения. Если в прошлой загрузке юнит запускался мгновенно, а в текущей висит, вопрос в изменениях: обновление, правка конфигурации, исчезнувший внешний ресурс.
Признаки внешней зависимости читаются в статусе юнита: ожидание устройства, ожидание сети, ожидание удалённого хранилища. Висящее ожидание почти всегда означает ресурс вне системы: диск, сервер хранилища, сетевой шлюз, и следующий шаг диагностики переходит туда, где живёт ресурс.
Классическая ошибка этого этапа: правка наугад, по первому подозрительному имени. Список заданий и журнал дают точный ответ за минуты, а правка наугад создаёт вторую проблему поверх первой. Аварийная оболочка располагает к спешке, и дисциплина сначала читать, потом править важна здесь больше, чем где-либо.
Типовые виновники от fstab до сетевых ожиданий
Первый по частоте виновник: запись в таблице монтирования, чей ресурс недоступен. Диск вынули, раздел переименовали, сервер сетевого хранилища ушёл, а запись в файле монтирований осталась. Задание монтирования висит до таймаута, а при строгих параметрах отправляет систему в аварийный режим при загрузке. Лечение начинается с параметров в записи: пометка необязательности и лимит времени ожидания устройства превращают исчезнувший ресурс в отложенную проблему, а не в остановленную загрузку:
nofail,x-systemd.device-timeout=10sВторой класс: ожидание сети. Целевой юнит сетевой готовности ждёт, пока интерфейсы поднимутся, а подниматься нечему: кабель выдернут, адрес недоступен, мост не собирается. Службы, зависящие от сетевой готовности, честно стоят в очереди. Диагноз читается в статусе сетевых юнитов, а решение начинается с вопроса, нужна ли службам эта зависимость на самом деле.
Третий класс: последствия обновлений. Свежая версия службы не стартует из-за изменившегося синтаксиса конфигурации, и её провал блокирует загрузку, если она оказалась в критическом пути. Журнал юнита покажет точную строку ошибки, и правка одного файла возвращает загрузку за минуту.
Четвёртый класс: накопители и разделы, изменившие имена после перестановки железа. Идентификаторы в таблице монтирования перестают совпадать с реальностью, задания ждут устройства, которого больше нет под старым именем. Постоянные идентификаторы вместо имён лечат класс навсегда, и именно после перестановок этот класс приходит чаще всего.
Пятый класс, редкий, но громкий: служба с бесконечным внутренним ожиданием, например база, не дождавшаяся своего каталога или удалённого комплекта. Висит сама служба, а не система, но в критическом пути загрузки эффект тот же: сообщение на экране и ожидание до таймаута.
Правка конфигурации и проверка перезагрузкой
Правка проводится в той же аварийной оболочке, после перемонтирования: виновная строка комментируется или снабжается лечащими параметрами, файл сохраняется, и система перезагружается. Первый цикл проверки ответственный: если правка вернула загрузку, экран молчит и сервер доезжает до приглашения, это успех, зафиксированный и в памяти, и в протоколе.
Вторая перезагрузка подтверждает устойчивость: единичные сбои иногда проходят от случайного стечения, и вторая холодная загрузка без ожиданий закрывает вопрос. Затянувшаяся диагностика обязана заканчиваться именно так: не "вроде грузится", а "грузится стабильно, время загрузки такое-то".
Для записей монтирования после лечения работает инструмент проверки таблицы: он ловит опечатки до перезагрузки, когда правка делалась в аварийной оболочке на глазах у усталого администратора. Минута проверки дешевле повторения аварийного входа, и инструмент входит в процедуру обязательно.
Откат планируется до правки: что вернуть на место, если предположение было неверным. Записанная команда отката и знание изначальной строки сохраняют спокойствие и время, когда первая гипотеза провалится, а она проваливается у всех.
Профилактика после лечения: список монтирований просматривается на предмет записей без параметров устойчивости, зависимости сетевой готовности проверяются на необходимость, а утилита анализа загрузки включается в регулярный осмотр. Однажды починенная загрузка не должна собираться ломаться снова.
Рабочая процедура разбора долгой загрузки
Процедура, сводящая разбор к двадцати минутам, выглядит так:
- Прочитать имя ожидающего юнита с экрана ожидания до любых действий;
- Войти в аварийный или спасательный режим подсказанными клавишами или через загрузчик;
- Перемонтировать корень и запросить список незавершённых заданий;
- Прочитать хвост журнала текущей загрузки и статус виновника;
- Проверить типовые причины: таблица монтирований, сетевые ожидания, недавние обновления;
- Исправить запись с лечащими параметрами, проверить синтаксис и перезагрузиться дважды.
За процедурой стоит привычка системы: загрузка никогда не зависает без причины, она всегда ждёт имени, и это имя всегда доступно. Администратор, знающий три команды чтения, никогда не остаётся перед зависшей загрузкой без инструментов.
Отдельная строка про коллективный опыт: процедуру разбора стоит провести вместе с младшим коллегой на учебном сервере, намеренно создав зависание монтирования. Одна совместная репетиция в спокойной обстановке стоит десятка консультаций по телефону в ночь реального сбоя, и рука, однажды входившая в аварийный режим, не дрожит потом.
Итоговое суждение по сценарию спокойное. Сообщение о задании запуска это не поломка системы, а её честность: менеджер называет, кого ждёт, и даёт войти, чтобы разобраться. Аварийная оболочка, список заданий и журнал отвечают на вопросы за минуты, типовые виновники известны наизусть, а лечащие параметры превращают хрупкие зависимости в устойчивые записи. Одна разобранная зависшая загрузка обучает процедуре навсегда, и следующий раз заканчивается не тревогой, а двадцатью минутами рутины.
Мелкая привычка с большим эффектом: после каждой успешной диагностики загрузки фиксируйте в заметке имя виновника и лечение. Через год заметка превращается в личный атлас типовых сбоев парка серверов, и половина следующих инцидентов распознаётся по первым строкам.