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

Нет, systemctl enable example.service настраивает автозагрузку, но не запускает службу в текущем сеансе. Чтобы служба заработала сразу, отдельно выполните sudo systemctl start example.service и проверьте результат через systemctl is-active или systemctl status. Включённая автозагрузка также не гарантирует успешный старт после перезагрузки.

Сохранит ли restart активные соединения службы?

Нет, systemctl restart не гарантирует сохранения активных соединений. Команда сначала останавливает unit, затем запускает его снова, поэтому прикладные подключения и выполняемые операции могут быть прерваны. Перед перезапуском критичной сетевой службы проверьте конфигурацию, подготовьте альтернативный доступ к серверу и запланируйте окно работ.

Нужно ли выполнять daemon-reload после изменения конфигурации приложения?

Обычно нет. systemctl daemon-reload нужен после добавления, удаления или изменения unit-файла либо его drop-in-конфигурации, чтобы systemd перечитал определения units. Если менялась только конфигурация приложения, используйте предусмотренный приложением reload или при необходимости restart. daemon-reload сам по себе не перезапускает службу.

Остановит ли disable уже работающую службу?

Нет, systemctl disable example.service не останавливает уже работающую службу. Эта команда удаляет ссылки enablement, связанные с автоматической активацией unit. Для остановки нужен отдельный вызов sudo systemctl stop example.service. Перед отключением нестандартно настроенного unit проверьте его ссылки: disable может удалить и совпадающие ссылки, созданные вручную.

Можно ли запустить службу со статусом disabled?

Да. Статус disabled не запрещает запуск службы вручную через systemctl start. Unit также может быть запрошен зависимостью или активирован через socket unit либо timer unit. Исключение — masked: замаскированный unit не может быть запущен, пока с него не снимут маску.

systemd и systemctl: управление службами и автозагрузкой Linux

Q: Почему enabled-служба может не запуститься после перезагрузки?

Потому что enabled означает только настроенный способ активации, а не успешный запуск. Загрузке могут помешать ошибка конфигурации, отсутствующая зависимость, условия запуска, недоступный ресурс или сбой самого приложения. После настройки автозагрузки проверяйте не только is-enabled, но и состояние службы и работу прикладной функции.

systemd — менеджер инициализации и служб Linux, который управляет именованными объектами units, их зависимостями, состоянием и активацией. Для ежедневного управления службами обычно достаточно systemctl status, start, stop, restart, reload, enable, disable, is-active и is-enabled. Важно различать текущее состояние службы и настройку её автозапуска: enabled означает способ активации настроен, но не гарантирует успешный запуск при следующей загрузке.

Что systemd управляет и как service unit связан со службой

На типичном Linux-хосте системный экземпляр systemd работает как PID 1 — первый процесс пользовательского пространства после запуска ядра. Он управляет не только системными службами, но и разными типами Systemd unit: например, .service, .socket, .timer, .mount и .target. Unit типа systemd target группирует другие units и используется как точка синхронизации при загрузке или смене состояния системы.

Service unit обычно описывает демон либо другой процесс, который systemd должен запустить, отслеживать и остановить. Процессы, запущенные для service unit, systemd объединяет в cgroup. Поэтому одна служба может включать не один, а несколько процессов: основной процесс и его дочерние процессы остаются частью управляемой группы.

Для штатно управляемой службы предпочтительнее использовать systemctl, а не искать PID и вручную посылать сигнал процесса. При операции над unit systemd учитывает его определение, зависимости и cgroup процессов. Ручной сигнал отдельному PID может затронуть не тот процесс или оставить дочерние процессы службы работающими.

Не каждый Linux использует systemd

systemd используется во многих современных выпусках Debian, Ubuntu Server, RHEL, Rocky Linux, AlmaLinux и CentOS Stream, но не является обязательным для любого Linux-сервера. В отдельных дистрибутивах, контейнерах и старых системах может применяться другая init-система. Некоторые systemd-дистрибутивы также предоставляют совместимость с устаревшими SysV init-скриптами; её поведение и доступность зависят от дистрибутива, выпуска и установленного пакета.

Как узнать имя службы и проверить её состояние

Имя unit зависит от дистрибутива, пакета и версии. Например, служба SSH в одной системе может быть ssh.service, а в другой — sshd.service. Не переносите имя из чужой инструкции без проверки: используйте команды ниже и сверяйтесь с документацией установленного пакета. Если суффикс не указан, systemctl обычно рассматривает имя как service unit, но в командах и автоматизации лучше указывать полный суффикс.

Показывает известные unit-файлы служб и их состояние enablement. Подходит для поиска установленной службы.

systemctl list-unit-files --type=service

Показывает загруженные service units, включая неактивные. Без `--all` команда по умолчанию не выводит часть неактивных units.

systemctl list-units --type=service --all

После определения имени проверьте службу через status. Команда показывает, загружено ли определение unit, его текущее состояние, сведения об основном процессе, если он определён, и часть последних сообщений, если они доступны. Это удобная первичная проверка, но не полная диагностика причины сбоя.

Показывает состояние условной службы `example.service`.

systemctl status example.service

Вывод:

● example.service
     Loaded: loaded (...)
     Active: active (running) ...

Проверяет только текущее состояние активности. При активном unit команда выводит, например, `active` и завершается с кодом 0; для неактивного или не найденного unit код завершения будет ненулевым.

systemctl is-active example.service

systemctl status также возвращает ненулевой код, если unit не активен или возникла другая проблема. Поэтому ожидаемое inactive после штатного stop само по себе не означает ошибку. В скриптах проверяйте одновременно ожидаемое состояние, вывод команды и её код завершения, а не только наличие ненулевого кода.

Если служба не запускается

Не повторяйте restart до фиксации исходных данных, если нужен разбор причины: повторный запуск меняет текущее состояние. Для диагностики failed, ошибок запуска и циклических перезапусков используйте статью «Служба systemd не запускается: диагностика ошибок и восстановление». Подробный просмотр записей через journalctl разобран в материале «Журналы Linux: journalctl, rsyslog и logrotate».

Запуск, остановка, перезапуск и reload службы

Ежедневное управление службой через systemctl

Замените example.service на проверенное имя нужной службы. Команды, которые меняют состояние системного unit, выполняются с sudo.

1
Проверьте исходное состояние
Выполните systemctl status example.service и при необходимости systemctl is-active example.service. Убедитесь, что имя unit соответствует нужному приложению и что операция не затронет критичную функцию.
2
Запустите службу, если она должна работать
Выполните sudo systemctl start example.service. Команда запрашивает запуск unit и его необходимых зависимостей, но не включает автозагрузку. Затем проверьте systemctl is-active example.service или systemctl status example.service.
3
Остановите службу, если требуется прекратить её работу
Выполните sudo systemctl stop example.service. После штатной остановки ожидаемо увидеть inactive; это не самостоятельный признак ошибки. Остановка не меняет настройку enablement.
4
Перезапустите службу для запуска нового процесса
Выполните sudo systemctl restart example.service. restart сначала останавливает unit, затем запускает его снова. Активные соединения и выполняемые операции приложения могут быть прерваны; сохранение соединений этой командой не гарантируется.
5
Запросите перечитывание конфигурации приложения, если оно поддерживается
Выполните sudo systemctl reload example.service только если документация unit и приложения предусматривает reload. При успешном reload процесс обычно не заменяется, но конкретное действие определяет приложение. Если unit не поддерживает перечитывание конфигурации без остановки, команда может завершиться ошибкой; тогда необходимость restart оценивают отдельно.
6
Проверьте ожидаемый результат
После start, restart или успешного reload проверьте systemctl status example.service и прикладную функцию. После stop подтвердите ожидаемое inactive через systemctl is-active example.service или status.

Смысл основных команд управления состоянием

Команда	Что делает	Чего не делает
`start`	Запрашивает запуск unit.	Не включает автозагрузку.
`stop`	Запрашивает остановку unit и процессов, которыми он управляет.	Не отключает автозагрузку.
`restart`	Останавливает unit и запускает его снова.	Не гарантирует сохранения соединений и успешного нового запуска.
`reload`	Вызывает предусмотренное unit действие перечитывания конфигурации работающей службы.	Не означает стандартный цикл полной остановки и запуска; конкретное поведение определяют unit и приложение. Для units без поддержки reload команда завершается ошибкой.
`try-restart`	Перезапускает unit только в том случае, если он уже активен.	Не запускает остановленную службу.

Риск потери удалённого доступа и простоя

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

Определите, какие приложения, пользователи и другие units зависят от службы.
Проверьте конфигурацию штатной командой самого приложения, если такая проверка предусмотрена его документацией.
Убедитесь, что есть альтернативный доступ: консоль управления, локальная консоль или другой независимый административный канал.
Выберите окно работ, если операция может разорвать соединения или остановить обработку запросов.
После операции проверяйте не только active, но и доступность нужной прикладной функции.

Автозагрузка Linux: enablement и текущее состояние — разные вещи

Текущее состояние отвечает на вопрос, работает ли unit сейчас; enablement — настроен ли механизм его активации при достижении определённого состояния системы или через другой unit. Поэтому активная служба может быть disabled, если её запустили вручную или активировал другой механизм. И наоборот, enabled-служба может быть сейчас остановлена.

Показывает состояние enablement, например `enabled`, `disabled`, `static`, `indirect`, `alias` или `masked`. Проверяйте прежде всего выведенное состояние: код 0 может возвращаться не только для `enabled`, но и для некоторых специальных состояний, включая `static`, `indirect` и `alias`. Точную таблицу состояний и кодов завершения сверяйте с документацией установленной версии systemd.

systemctl is-enabled example.service

Включает предусмотренную unit настройку активации. Команда не запускает службу в текущем сеансе.

sudo systemctl enable example.service

Удаляет подходящие символические ссылки enablement из каталогов конфигурации systemd. Команда может удалить и совпадающие ссылки, созданные вручную, поэтому перед её применением к нестандартно настроенному unit проверьте его ссылки. Уже работающую службу `disable` не останавливает.

sudo systemctl disable example.service

Различие операций и проверок

Команда	Область действия	Типичный результат
`is-active`	Текущее состояние unit	Показывает, активен ли unit сейчас.
`start` / `stop`	Текущее состояние unit	Запускает или останавливает службу без изменения enablement.
`is-enabled`	Настройка enablement	Показывает, включена ли установка ссылок для активации и какое специальное состояние имеет unit.
`enable` / `disable`	Настройка enablement	Создаёт или удаляет установочные ссылки, но не запускает и не останавливает unit.

При systemctl enable systemd использует установочную информацию unit, обычно из секции [Install]. В частности, директивы WantedBy= и RequiredBy= задают units, для которых создаются символические ссылки зависимостей; эти units не обязаны быть units типа target. Alias= создаёт дополнительные имена unit, а Also= указывает units, которые также следует обработать при enable или disable. Точный набор ссылок зависит от определения конкретного unit.

Не каждый unit имеет собственную установочную конфигурацию. Поэтому вывод is-enabled нельзя упрощать до двух состояний. static обычно означает, что у unit нет данных [Install] для самостоятельного включения: его могут запускать вручную или активировать зависимости. indirect обычно означает, что установочная информация есть, но unit предназначен для косвенного включения — например, через Also= или alias. alias обозначает имя-псевдоним другого unit. masked означает, что unit замаскирован и не может быть запущен, пока не будет снята маска. Полную трактовку состояний для установленной версии systemd сверяйте с документацией systemctl.

enabled не подтверждает, что служба успешно запустится при следующей загрузке: могут помешать ошибка конфигурации, отсутствующая зависимость, условия запуска, недоступный ресурс или сбой приложения. disabled также не запрещает запуск полностью: unit можно запустить вручную, он может быть затребован зависимостью, активирован socket unit или timer unit. Настройка заданий через timers рассматривается отдельно в статье «Cron и systemd timers: создание задач по расписанию и диагностика сбоев».

Когда нужен systemctl daemon-reload

После добавления, удаления или изменения unit-файла либо его drop-in-конфигурации systemd должен перечитать определения units. Для этого используют daemon-reload.

Перечитывает unit-файлы и конфигурацию менеджера systemd.

sudo systemctl daemon-reload

daemon-reload не запускает службу, не перезапускает уже работающий процесс, не включает автозагрузку и не применяет конфигурацию самого приложения. Если изменялась конфигурация приложения, нужен документированный для него reload либо, при необходимости, restart. Создание service unit и выбор его параметров рассмотрены отдельно в статье «Как создать службу systemd для собственного приложения или скрипта».

Не путайте daemon-reload с reload: первая команда перечитывает определения units самим менеджером systemd, вторая передаёт запрос работающей службе. Команда systemctl daemon-reexec перезапускает сам процесс менеджера systemd с сохранением его состояния, насколько это возможно; это не обычный шаг ежедневного управления службой и применяется только для специальных административных сценариев по документации systemd и дистрибутива.

Пользовательские units

Команда systemctl --user управляет units экземпляра systemd конкретного пользователя, а не системными службами. Их жизненный цикл, права и enablement отличаются от системного экземпляра; приведённые выше команды без --user относятся к системному управлению.

Термины в статье

Демон: Демон — обычно длительно работающий неинтерактивный процесс, который в фоне выполняет системную, сетевую или прикладную функцию.
Процесс: Процесс — экземпляр выполняемой программы в Linux с PID, виртуальным адресным пространством, состоянием и связанными с ним ресурсами.
Сигнал процесса: Сигнал процесса — уведомление о событии в Unix-подобной ОС, которое ядро доставляет процессу или потоку для выполнения заданного действия.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
AlmaLinux: AlmaLinux — корпоративный дистрибутив Linux, поддерживаемый сообществом и AlmaLinux OS Foundation, ориентированный на совместимость с интерфейсами и экосистемой RHEL.
CentOS Stream: CentOS Stream — дистрибутив Linux с непрерывной поставкой пакетов, формирующих следующую минорную версию Red Hat Enterprise Linux; он расположен между Fedora и RHEL.
cgroup: cgroup — механизм ядра Linux для объединения процессов в иерархические группы с раздельным учётом и управлением потреблением ресурсов.
Debian: Debian — универсальный дистрибутив Linux с пакетами DEB и системой APT, известный консервативной веткой Stable и разделением репозиториев по веткам разработки.
journalctl: journalctl — консольная утилита чтения и фильтрации журнала systemd, выводящая сообщения по времени, юниту, загрузке системы, приоритету и другим полям.
PID: PID — числовой идентификатор экземпляра процесса, назначаемый ядром Linux для его адресации; после завершения процесса номер может быть использован повторно.
RHEL: RHEL — корпоративный дистрибутив Linux от Red Hat с фиксированными основными версиями, сертификационной экосистемой и моделью сопровождения, зависящей от подписки.
Rocky Linux: Rocky Linux — корпоративный дистрибутив Linux, создаваемый из исходных пакетов экосистемы RHEL и ориентированный на совместимость с RHEL без использования его товарных знаков.
SSH: SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
systemctl: systemctl — командная утилита управления systemd, которая запускает и останавливает юниты, показывает их состояние и настраивает автоматическую активацию.
systemd: systemd — система инициализации и менеджер служб Linux, управляющий службами и другими ресурсами как объектами unit, обычно описанными unit-файлами.
systemd target: systemd target — unit типа target, группирующий другие units и служащий точкой синхронизации при загрузке или изменении состояния системы.
Systemd unit: Systemd unit — именованный объект systemd, представляющий отслеживаемый или управляемый ресурс, службу, задачу либо состояние системы.
systemd-journald: systemd-journald — служба systemd для приёма, индексации и хранения структурированных журналов ядра, служб, процессов и системных сообщений.
Ubuntu Server: Ubuntu Server — серверный вариант дистрибутива Ubuntu на базе Debian с APT и типовыми средствами автоматизации, доступный в виде установочных и готовых образов.