Зависшая служба systemd при загрузке Linux как найти причину через journalctl и вернуть нормальный запуск

Сообщение A start job is running for... появляется, когда systemd ждёт завершения некоторой операции во время запуска системы. На экране может отображаться название службы, устройства или другого задания, а рядом счётчик вроде 1min 30s / no limit либо ограничение по времени. Пока ожидаемая операция не завершится, загрузка может стоять на одном месте несколько минут.

Такая ситуация не всегда означает, что сама служба сломана. Причиной может оказаться недоступный диск, сетевой ресурс, устройство, неправильная зависимость или программа, которая не отвечает в ожидаемый срок. Поэтому отключать первую попавшуюся службу без диагностики рискованно.

Основная задача состоит в том, чтобы получить имя проблемного задания, посмотреть сообщения systemd и журнал загрузки, а затем решить, действительно ли службу можно временно убрать из автоматического запуска. Если проблема связана именно с необязательной службой, команда systemctl disable часто позволяет вернуть нормальную загрузку без удаления пакетов или изменения конфигурации самой программы. Red Hat отдельно отмечает, что отключённая служба перестаёт запускаться автоматически, но остаётся доступной для ручного запуска.

Что означает сообщение A start job is running при запуске Linux

В основе сообщения лежит механизм заданий systemd. Во время загрузки менеджер служб запускает units и отслеживает зависимости между ними. Для службы создаётся задание на запуск, а systemd ждёт результата. Если программа не завершает старт, не появляется нужное устройство или не выполняется зависимость, задание остаётся ожидающим.

На экране это может выглядеть примерно так:

A start job is running for Network Manager Wait Online
(1min 30s / no limit)

Или:

A start job is running for /dev/disk/by-uuid/...
(2min 0s / no limit)

Эти два случая внешне похожи, но исправляются по-разному. В первом случае подозрение падает на службу, связанную с ожиданием сети. Во втором проблема может находиться в цепочке монтирования диска или в самом устройстве.

Особенно полезна часть строки после for. Именно там обычно находится первый ориентир для поиска причины. Если система показывает название foo.service, работать нужно с unit foo.service. Если указано устройство, путь к файловой системе или mount point, нельзя автоматически считать виноватой службу с похожим названием.

Фраза no limit тоже не означает, что systemd навсегда завис именно на этой службе. Она показывает, что для конкретного задания нет обычного ограничителя времени, после которого операция должна быть автоматически прервана. Поэтому экран может оставаться без изменений значительно дольше, чем ожидает пользователь.

В некоторых конфигурациях задания действительно имеют тайм-ауты, а systemd способен завершить операцию после их истечения. Механизм тайм-аутов относится к самим job и настройкам соответствующих units, поэтому продолжительность ожидания зависит от конкретной ситуации.

Главная мысль здесь простая: надпись на экране сообщает о симптоме, а не обязательно о виновнике. Для точного ответа нужен журнал.

Как получить доступ к терминалу если графическая загрузка остановилась

Если система не дошла до рабочего стола, необязательно сразу перезагружать компьютер. Во многих Linux можно переключиться на другую виртуальную консоль через сочетание Ctrl + Alt + F3, F4, F5 или другую доступную клавишу F.

После переключения появится текстовый экран входа. Нужно войти под обычной учётной записью и получить права администратора через sudo.

Например:

sudo -i

После этого команды диагностики можно выполнять от имени root.

Количество доступных TTY и конкретные сочетания клавиш зависят от дистрибутива, графической среды и конфигурации. Если переключение на другую консоль не срабатывает, остаётся вариант с режимом восстановления или временным запуском другого target через загрузчик.

Для диагностики systemd предусмотрены rescue и emergency режимы. Emergency mode даёт минимальную среду, в которой корневая файловая система обычно подключается только для чтения, дополнительные локальные файловые системы не монтируются, а сеть не поднимается. Это позволяет работать с системой даже тогда, когда обычная последовательность запуска не проходит.

Если меню GRUB доступно, можно временно добавить к строке запуска ядра параметр:

systemd.unit=emergency.target

Для этого в меню загрузчика выбирают нужную запись, нажимают e, находят строку, начинающуюся с linux, добавляют параметр в конец и запускают изменённую запись сочетанием Ctrl + X. Такое изменение действует только для текущего запуска.

Для более мягкого варианта можно использовать:

systemd.unit=rescue.target

Rescue mode запускает больше компонентов, чем emergency mode, поэтому он удобнее, если для диагностики нужны дополнительные файловые системы или другие службы. Если rescue mode не запускается, emergency mode остаётся более минимальным вариантом восстановления.

Как определить зависшую службу через systemctl и журнал systemd

После получения терминала первым делом полезно посмотреть состояние системы:

systemctl --failed

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

Следующий шаг:

systemctl list-jobs

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

Полезно посмотреть и общую информацию:

systemctl status

Для конкретной службы:

systemctl status имя-службы.service

Например:

systemctl status NetworkManager-wait-online.service

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

Отдельно стоит проверить журнал:

journalctl -b

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

Для сообщений с ошибками можно использовать:

journalctl -b -p err

А для конкретной службы:

journalctl -b -u имя-службы.service

Например:

journalctl -b -u NetworkManager-wait-online.service

Если проблема возникла ещё до полноценного запуска текущей системы, полезно посмотреть предыдущую загрузку:

journalctl -b -1

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

Удобный вариант для просмотра последних сообщений:

journalctl -b -n 100

А для наблюдения за журналом в реальном времени:

journalctl -f

Если служба пишет понятное сообщение вроде failed to mount, dependency failed, timed out, connection refused или no such device, дальнейший поиск становится намного точнее.

Полезно сопоставлять несколько источников. systemctl list-jobs показывает текущие задания, systemctl status раскрывает состояние конкретного unit, а journalctl показывает события и сообщения, которые привели к этому состоянию. Только один из этих инструментов иногда даёт слишком мало информации.

Как понять что служба действительно виновата в задержке

Самая частая ошибка при такой диагностике состоит в том, чтобы считать виновником первую строку, которую пользователь увидел на экране. Systemd запускает связанные units через зависимости, поэтому ожидаемая операция может быть следствием другой неисправности.

Например, экран может ждать сетевую службу, а настоящая причина находится в неправильной конфигурации сети. В другом случае systemd ждёт монтирования файловой системы, а проблема заключается в диске или неверной записи в /etc/fstab.

Для анализа времени загрузки пригодится:

systemd-analyze

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

Ещё полезнее:

systemd-analyze blame

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

Для анализа зависимостей используется:

systemd-analyze critical-chain

Команда показывает критическую цепочку запуска, то есть последовательность units, которая определяет прохождение соответствующего участка загрузки. Red Hat рекомендует этот инструмент для поиска units, которые сильнее всего замедляют запуск.

При этом blame не следует воспринимать как окончательный вердикт. Долгое время работы службы не всегда означает ошибку. Некоторые сервисы закономерно запускаются дольше остальных. Смысл анализа состоит в сопоставлении времени с журналом и зависимостями.

Если на экране указана конкретная служба, можно проверить её зависимости:

systemctl list-dependencies имя-службы.service

Для обратной связи полезен и вариант:

systemctl list-dependencies --reverse имя-службы.service

Он помогает понять, какие units зависят от выбранной службы.

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

Как временно отключить проблемную службу перед перезагрузкой

Если журнал показывает, что задержку вызывает необязательная служба, а сама система после её отключения сможет нормально работать, её можно убрать из автоматического запуска:

systemctl disable имя-службы.service

Например:

systemctl disable example.service

disable изменяет механизм автоматического запуска unit. Служба при этом не удаляется, её файлы не стираются, а ручной запуск остаётся возможным. Документация Red Hat прямо описывает это различие: отключённая служба не запускается автоматически при загрузке, но её можно запустить вручную.

После отключения можно проверить состояние:

systemctl is-enabled example.service

Ожидаемым результатом будет:

disabled

Если служба уже работает в текущей сессии и требуется остановить её сразу, существует вариант:

systemctl disable --now example.service

Но при восстановлении системы лучше не добавлять --now без необходимости. Если задача состоит именно в том, чтобы не запускать службу при следующей загрузке, обычного disable достаточно. Если же служба уже успела запуститься и продолжает мешать, --now позволяет одновременно остановить её. Такая возможность предусмотрена самим systemctl.

Для безопасного восстановления полезно сначала записать точное имя unit:

systemctl status example.service

Затем отключить именно его:

systemctl disable example.service

После этого выполнить перезагрузку:

reboot

Если система загрузилась нормально, проблема была связана с автоматическим запуском этой службы или с одной из её зависимостей. Но на этом диагностику лучше не считать законченной.

Почему systemctl disable не всегда исправляет зависание

systemctl disable действует на автоматический запуск конкретного unit. Если проблема находится в другой зависимости, отключение наблюдаемой службы может ничего не изменить.

Например, если загрузка ждёт:

A start job is running for /dev/disk/by-uuid/...

отключение случайной службы не решит проблему с диском. В такой ситуации нужно искать сообщения mount, device, fsck, dependency и ошибки файловой системы в журнале.

Если экран показывает:

A start job is running for NetworkManager-wait-online.service

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

Есть и другой важный момент. Служба может быть запущена не через enable, а как зависимость другого unit. Поэтому команда:

systemctl is-enabled example.service

не всегда объясняет, почему unit стартует.

Для поиска связей помогают:

systemctl list-dependencies

и:

systemctl list-dependencies --reverse example.service

При необходимости можно посмотреть фактическую конфигурацию:

systemctl cat example.service

Здесь видны настройки unit, включая зависимости, команды запуска и другие параметры. Такой просмотр безопаснее, чем сразу редактировать системные файлы.

Отдельно существует команда mask, но для обычного восстановления после зависания она обычно слишком жёсткая. Маскирование запрещает запуск unit не только автоматически, но и вручную, пока его не размаскируют. Red Hat описывает mask именно как более строгую форму запрета запуска.

Поэтому последовательность обычно выглядит разумнее так: сначала диагностика, затем disable, а mask применяется только тогда, когда требуется гарантированно запретить запуск конкретного unit.

Что делать если служба отключена а загрузка всё равно висит

Если после disable проблема осталась, не стоит бесконечно повторять ту же команду. Следующий шаг заключается в поиске другого ожидающего job.

Сначала:

systemctl list-jobs

Затем:

systemctl --failed

После этого:

journalctl -b -p err

И для анализа времени:

systemd-analyze blame

Если проблема связана с зависимостями, полезно проверить критическую цепочку:

systemd-analyze critical-chain

Если компьютер загружается после отключения одной службы, но затем перестаёт работать конкретная функция, службу можно вернуть:

systemctl enable имя-службы.service

Если требуется сразу запустить её:

systemctl enable --now имя-службы.service

Команда enable --now одновременно включает автоматический запуск и запускает unit в текущей сессии.

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

Как найти причину задержки по типу сообщения на экране

Текст после for часто подсказывает направление поиска. Если упоминается mount, проверяется файловая система и настройки монтирования. Если присутствует device, внимание переключается на устройство и его доступность. Если указана конкретная .service, исследуется unit и его журнал. Если встречается dependency, нужно смотреть цепочку связанных units.

Для службы можно начать с:

systemctl status имя-службы.service
journalctl -b -u имя-службы.service

Для загрузки целиком:

journalctl -b

Для ошибок:

journalctl -b -p err

Для текущих заданий:

systemctl list-jobs

Для критической цепочки:

systemd-analyze critical-chain

Эти команды позволяют перейти от абстрактного "Linux завис" к конкретной последовательности событий. Например, журнал может показать, что служба ждёт устройство, устройство не появляется, а другое задание продолжает ждать службу. Тогда становится понятно, что отключение последнего элемента цепочки лишь маскирует первичную проблему.

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

Восстановление загрузки без удаления службы и конфигурации

Зависшая служба systemd редко требует радикальных действий. В большинстве случаев достаточно получить доступ к shell, определить имя ожидающего задания, проверить systemctl status, посмотреть journalctl -b и только после этого решить, нужна ли служба при старте.

Если подтверждено, что служба необязательна и именно её запуск мешает загрузке, используется:

systemctl disable имя-службы.service

После перезагрузки система должна пропустить автоматический запуск этой службы. При этом сама служба остаётся установленной и может быть включена обратно после исправления причины. Такой принцип соответствует назначению disable: запретить автоматический запуск, сохранив возможность ручного управления unit.

Для аварийной диагностики, когда обычная загрузка вообще не проходит, пригодится временный запуск rescue.target или emergency.target через параметры GRUB. Red Hat рекомендует emergency mode как минимальную среду для поиска проблем с загрузкой, а изменение target через загрузчик действует только на один запуск.

Самый практичный порядок действий можно свести к такой последовательности:

1. Переключиться на TTY или загрузиться в rescue/emergency mode, если графическая загрузка не продолжается;

2. Выполнить systemctl list-jobs и systemctl --failed, чтобы увидеть текущие задания и ошибки;

3. Найти конкретную службу по сообщению на экране и проверить её через systemctl status, а подробности взять из journalctl -b -u имя-службы.service;

4. Если виновата необязательная служба, выполнить systemctl disable имя-службы.service и проверить загрузку после перезапуска;

5. Если проблема осталась, исследовать зависимости, файловые системы, устройства и критическую цепочку через systemd-analyze critical-chain, а не отключать службы одну за другой;

6. После успешной загрузки исправить первопричину и при необходимости вернуть службу командой systemctl enable имя-службы.service.

Главное здесь не перепутать временное восстановление с ремонтом. systemctl disable способен быстро вернуть загрузку, но он не объясняет, почему служба зависла. Если причина связана с диском, сетью, зависимостью или ошибкой конфигурации, она останется на месте.

Поэтому сообщение A start job is running for... лучше воспринимать как подсказку systemd. Оно показывает, на каком этапе загрузка ждёт продолжения. Дальше решение строится вокруг трёх источников информации: текущих заданий systemctl list-jobs, состояния конкретного unit через systemctl status и событий из journalctl. Когда эти данные сопоставлены, становится гораздо проще понять, что именно задерживает запуск и можно ли безопасно отключить службу.