Служба, юнит и две независимые вещи: сейчас и при загрузке
В большинстве современных дистрибутивов Linux службами управляет systemd, а его пульт — команда systemctl. Каждая служба описана файлом-юнитом с названием вроде имя.service. Суффикс .service при вводе обычно можно опустить.
Главная идея, на которой строится вся работа: у службы два независимых состояния. Первое — запущена ли она прямо сейчас. Второе — будет ли она запускаться при загрузке системы. Команды start и stop меняют первое, а enable и disable меняют второе. Поэтому после enable служба не запустится сама в этот момент, если вы не добавите ключ --now, а после start она не вернётся после перезагрузки, пока вы не включите автозапуск.
Для изменения состояний нужны права администратора, то есть sudo. Просмотр состояния доступен и обычному пользователю. На macOS systemctl нет, там его роль играет launchd, а в контейнерах и в некоторых дистрибутивах systemd вообще не используется, поэтому проверьте, что он у вас есть, командой systemctl --version.
Основные команды в одной таблице
Набор команд небольшой, и им покрывается почти вся повседневная работа.
| Команда | Что делает |
|---|---|
| systemctl status имя | состояние, PID, использование памяти, последние строки журнала |
| sudo systemctl start имя | запустить сейчас |
| sudo systemctl stop имя | остановить сейчас |
| sudo systemctl restart имя | остановить и запустить заново |
| sudo systemctl reload имя | попросить перечитать настройки без остановки, если служба умеет |
| sudo systemctl enable имя | включить автозапуск при загрузке |
| sudo systemctl disable имя | выключить автозапуск |
| sudo systemctl enable --now имя | включить автозапуск и сразу запустить |
| systemctl is-active имя | коротко: active или inactive |
| systemctl is-enabled имя | коротко: enabled или disabled |
Команда is-active и is-enabled удобны в скриптах, так как возвращают понятный код завершения. Если вы не уверены, умеет ли служба reload, проверьте её документацию: при отсутствии поддержки команда сообщит об ошибке, а restart сработает всегда, но ненадолго прервёт работу.
Как читать вывод systemctl status
Первая строка вывода содержит название и краткое описание. Строка Loaded показывает, откуда прочитан файл юнита и включён ли автозапуск (enabled или disabled). Строка Active — главная: active (running) означает, что служба работает, inactive (dead) — остановлена, failed — завершилась с ошибкой. Рядом указано, как давно произошла смена состояния.
Дальше идут идентификатор главного процесса, число задач, потребление памяти и дерево процессов службы. Внизу выводятся последние строки журнала, и именно они часто сразу называют причину: занятый порт, отсутствующий файл, ошибка в настройках, отказ в доступе.
Состояние failed не лечится повторным нажатием на start, пока причина не устранена. Сначала прочитайте журнал полностью: journalctl -u имя -n 100 --no-pager. Как фильтровать журнал по времени и загрузке, показывает справка по команде journalctl. Если после правки настроек состояние остаётся failed, сбросить пометку позволяет systemctl reset-failed имя, но она лишь убирает отметку, а не решает проблему.
Порядок действий, если служба не стартует
Когда служба упорно не запускается, двигайтесь по шагам и меняйте что-то одно за раз.
- Выполните systemctl status имя и прочитайте последние строки: часто причина написана прямо там.
- Откройте полный журнал: journalctl -u имя -b --no-pager. Ищите первое сообщение об ошибке, а не последнее.
- Проверьте конфигурационный файл службы. У многих программ есть режим проверки настроек; его название смотрите в документации программы.
- Проверьте порт: если служба должна слушать порт, возможно, он уже занят другой программой. Как это выяснить, показывает страница про команду ss.
- Проверьте права на файлы и каталоги, которые читает служба; она работает под своим пользователем, а не под вашим.
- Если вы меняли файл юнита, выполните sudo systemctl daemon-reload, иначе systemd продолжит использовать прежнее описание.
- Запустите службу заново и сверьте результат с журналом.
Обращайте внимание на часть Restart в описании: служба может быть настроена на перезапуск при сбое, и в журнале вы увидите цепочку попыток.
Списки юнитов и поиск проблемных мест
Чтобы увидеть общую картину, пригодятся команды-обзоры.
- systemctl list-units --type=service — запущенные службы;
- systemctl list-units --failed — те, что завершились с ошибкой; это быстрый способ найти неполадку после загрузки;
- systemctl list-unit-files --type=service — все службы с признаком автозапуска;
- systemctl list-timers — таймеры systemd, замена части заданий cron;
- systemd-analyze blame — какие службы дольше всего стартовали при загрузке, если система загружается медленно.
Не отключайте службы, названия которых вам незнакомы. Многие из них нужны для сети, звука, часов и входа в систему, и последствия отключения проявляются не сразу. Если хочется ускорить загрузку, отключайте только то, что вы установили сами и понимаете назначение, а после изменения проверяйте перезагрузкой. Для временного отказа от службы есть вариант mask, который не позволяет запускать её даже вручную, но используйте его осознанно и помните, как отменить: unmask.
Аккуратность на рабочем сервере
На сервере, который используют другие люди, служба — это чья-то работа. Остановка или перезапуск прерывают подключения, поэтому делайте их в согласованное время и по возможности используйте reload. Перед правкой конфигурации сделайте копию файла, после правки проверьте синтаксис и только потом перезагружайте службу.
Если вы удалённо управляете службой удалённого доступа к самому серверу, будьте особенно осторожны: ошибка в настройках перед перезапуском может отрезать вам вход. Держите вторую сессию открытой, как описано на странице про вход по ключу, и проверяйте новое подключение до закрытия старого.
Записывайте внесённые изменения: что поменяли, когда и зачем. Через месяц это экономит часы поиска причины. А если неполадка не очевидна, соберите вывод status и фрагмент журнала: с ними обращение в поддержку или к коллегам станет предметным и быстрым.