Освоение systemctl: Основные команды для управления службами Linux

Если вы управляете серверами Linux, вы будете постоянно использовать systemctl. Вы используете его, когда Nginx не запускается, когда PostgreSQL должен запуститься после перезагрузки, когда развертывание требует чистой перезагрузки и когда служба сообщает «сбой», но настоящая ошибка скрыта в журнале.

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

Понимание systemd и systemctl

systemd — это система инициализации и менеджер служб, используемый многими основными дистрибутивами Linux, включая распространенные версии Debian, Ubuntu, Fedora и семейства RHEL. Он инициализирует пользовательское пространство и управляет процессами, сеансами, таймерами, сокетами, точками монтирования и службами.

systemctl — это основная утилита командной строки, используемая для управления и проверки состояния менеджера systemd и его компонентов (юнитов). Службы, которые представляют собой программы, работающие в фоновом режиме (демоны), управляются как сервисные юниты (обычно заканчиваются на .service).

Ключевые концепции: Юниты и Цели

Хотя эта статья посвящена службам, помните, что systemctl управляет различными юнитами:

Сервисные юниты (.service): Для управления фоновыми процессами (например, nginx.service).
Целевые юниты (.target): Для группировки юнитов вместе для представления определенного состояния системы (например, multi-user.target, который представляет типичную серверную среду).

Основные команды для управления службами (Состояние выполнения)

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

1. Запуск службы

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

sudo systemctl start <имя_службы>.service
# Пример: Запуск веб-сервера Apache
sudo systemctl start apache2.service

2. Остановка службы

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

sudo systemctl stop <имя_службы>.service
# Пример: Остановка службы базы данных MySQL
sudo systemctl stop mariadb.service

3. Перезапуск службы

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

sudo systemctl restart <имя_службы>.service
# Пример: Перезапуск демона SSH
sudo systemctl restart sshd.service

4. Перезагрузка конфигурации

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

sudo systemctl reload <имя_службы>.service
# Пример: Перезагрузка конфигурации Nginx
sudo systemctl reload nginx.service

Совет: Всегда проверяйте документацию службы. Если служба не поддерживает reload, после изменений конфигурации необходимо использовать restart.

Основные команды для постоянства службы (Состояние загрузки)

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

1. Включение службы

Чтобы гарантировать, что служба запускается автоматически после перезагрузки, вы должны включить ее. Это создает необходимые символические ссылки в каталогах конфигурации systemd (/etc/systemd/system/).

sudo systemctl enable <имя_службы>.service
# Пример: Включение PostgreSQL для запуска при загрузке
sudo systemctl enable postgresql.service

2. Отключение службы

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

sudo systemctl disable <имя_службы>.service
# Пример: Отключение службы Bluetooth на сервере
sudo systemctl disable bluetooth.service

3. Маскирование службы

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

sudo systemctl mask <имя_службы>.service

# Чтобы отменить маскирование:
sudo systemctl unmask <имя_службы>.service

Проверка состояния и информации о службе

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

1. Проверка состояния

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

systemctl status <имя_службы>.service
# Пример: Проверка состояния брандмауэра
systemctl status firewalld.service

Интерпретация вывода:

Ищите три ключевые строки в выводе:

Loaded: Показывает, был ли файл юнита загружен правильно (например, loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)).
Active: Показывает текущее состояние выполнения (например, active (running) или failed).
CGroup: Показывает дерево процессов, связанных со службой.

2. Запрос постоянства загрузки

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

systemctl is-enabled <имя_службы>.service
# Вывод будет 'enabled', 'disabled' или 'masked'

3. Просмотр журналов с помощью journalctl

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

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

# Просмотр всех журналов службы с момента последней перезагрузки
journalctl -u <имя_службы>.service

# Просмотр журналов в реальном времени (как tail -f)
journalctl -u <имя_службы>.service -f

# Просмотр журналов со вчерашнего дня
journalctl -u <имя_службы>.service --since "yesterday"

Предупреждение: Если служба показывает статус failed, journalctl -u <служба> -r (обратный порядок, сначала новые) часто является самым быстрым способом увидеть сообщение об ошибке, вызвавшее сбой.

4. Проверка, работает ли служба, в скриптах

Для скриптов оболочки systemctl status слишком многословен. Используйте команды запроса:

systemctl is-active --quiet nginx.service
echo $?

systemctl is-failed nginx.service
systemctl is-enabled nginx.service

is-active --quiet возвращает полезный код выхода без печати полной страницы состояния. Это делает его лучше для проверок работоспособности и автоматизации.

if ! systemctl is-active --quiet nginx.service; then
    echo "nginx не работает" >&2
    exit 1
fi

5. Список юнитов

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

systemctl list-units --type=service
systemctl list-units --type=service --state=failed
systemctl list-unit-files --type=service

list-units показывает загруженные юниты и их текущее состояние выполнения. list-unit-files показывает файлы юнитов и то, включены ли они, отключены, статичны, замаскированы или сгенерированы. Это различие объясняет, почему служба может существовать на диске, но не отображаться в списке активных юнитов.

Управление состоянием системы (Цели)

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

1. Просмотр текущего состояния системы

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

systemctl get-default

2. Изменение цели загрузки по умолчанию

Если вы настраиваете сервер, который никогда не должен запускать графический интерфейс, вы можете установить цель по умолчанию на multi-user.target:

sudo systemctl set-default multi-user.target

3. Перезагрузка и выключение

Хотя команды reboot и shutdown по-прежнему работают, systemctl предоставляет собственный способ выполнения этих действий:

# Немедленная перезагрузка системы
sudo systemctl reboot

# Остановка системы (выключение питания)
sudo systemctl poweroff

Перезагрузка systemd после изменений юнитов

Когда вы редактируете файл юнита или добавляете drop-in в /etc/systemd/system, systemd не перечитывает его автоматически. Выполните:

sudo systemctl daemon-reload

Затем перезапустите или перезагрузите затронутую службу:

sudo systemctl restart myapp.service

Чтобы проверить окончательный юнит после объединения файлов поставщика и drop-in:

systemctl cat myapp.service
systemctl show myapp.service -p FragmentPath -p DropInPaths

Это один из самых быстрых способов выявить проблемы типа «я отредактировал не тот файл».

Реальный поток устранения неполадок

Когда служба не запускается, работайте в таком порядке:

Проверьте состояние:

systemctl status myapp.service

Прочитайте журналы для этого юнита:

journalctl -u myapp.service -r

Если вы недавно редактировали файл службы, перезагрузите systemd:

sudo systemctl daemon-reload

Запустите его снова и следите за журналами в реальном времени:

sudo systemctl restart myapp.service
journalctl -u myapp.service -f

Если он сразу выходит из строя, проверьте определение юнита:

systemctl cat myapp.service
systemctl show myapp.service -p ExecStart -p User -p WorkingDirectory

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

Запуск, Включение, Перезапуск, Перезагрузка: Ментальная модель

Эти четыре глагола легко перепутать:

start изменяет текущее состояние выполнения.
enable изменяет поведение при загрузке.
restart останавливает и запускает процесс.
reload просит существующий процесс перечитать конфигурацию, если служба это поддерживает.

Например, после установки Nginx:

sudo systemctl start nginx.service
sudo systemctl enable nginx.service

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

После редактирования конфигурации Nginx сначала протестируйте конфигурацию приложения, затем перезагрузите:

sudo nginx -t
sudo systemctl reload nginx.service

Если приложение не поддерживает перезагрузку, используйте перезапуск и планируйте прерывание:

sudo systemctl restart myapp.service

Безопасное использование маскирования

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

sudo systemctl mask bluetooth.service
systemctl is-enabled bluetooth.service

Служба сообщает masked. Чтобы отменить это:

sudo systemctl unmask bluetooth.service

Используйте маскирование для явных конфликтов, например, чтобы предотвратить запуск старой службы после ее замены новой. Для обычного поведения «не запускать при загрузке» используйте disable.

Редактирование юнитов поддерживаемым способом

Когда вам нужно изменить упакованную службу, избегайте прямого редактирования файлов в /usr/lib/systemd/system или /lib/systemd/system. Обновления пакетов могут заменить эти файлы. Используйте переопределение:

sudo systemctl edit myapp.service

Это создает drop-in в /etc/systemd/system/myapp.service.d/. Например:

[Service]
Environment=APP_ENV=production
Restart=on-failure
RestartSec=5s

Затем примените его:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service

Если вам нужно удалить переопределение позже, сначала проверьте drop-in:

systemctl show myapp.service -p DropInPaths

Затем удалите конкретный файл drop-in и выполните daemon-reload. Это сохраняет локальные изменения видимыми и упрощает аудит.

Пользовательские службы

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

systemctl --user status pipewire.service
systemctl --user restart my-user-job.service

Пользовательские службы не используют sudo таким же образом, и они находятся в экземпляре systemd пользователя. Если команда работает с systemctl --user, но не с обычным systemctl, вы смотрите на пользовательский юнит, а не на системный.

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

loginctl enable-linger deploy

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

Сводка основных команд systemctl

Действие	Синтаксис команды	Назначение
Запустить сейчас	`sudo systemctl start name.service`	Запускает службу немедленно.
Остановить сейчас	`sudo systemctl stop name.service`	Завершает работающую службу.
Перезапустить	`sudo systemctl restart name.service`	Останавливает, а затем запускает службу.
Перезагрузить	`sudo systemctl reload name.service`	Применяет изменения конфигурации без полного перезапуска, если поддерживается.
Включить	`sudo systemctl enable name.service`	Настраивает службу на запуск при загрузке.
Отключить	`sudo systemctl disable name.service`	Предотвращает запуск службы при загрузке.
Статус	`systemctl status name.service`	Проверяет состояние выполнения и последние журналы.
Просмотр журналов	`journalctl -u name.service`	Предоставляет доступ к полной истории журнала systemd для службы.

Эти команды покрывают большую часть повседневной работы со службами. Start и stop управляют текущим процессом. Enable и disable управляют поведением при загрузке. Status, is-active и journalctl сообщают вам, что произошло. daemon-reload синхронизирует systemd с изменениями файлов юнитов. Когда вы держите эти роли раздельно, systemctl становится практическим инструментом устранения неполадок, а не командой, которую вы копируете из старых заметок.