systemctl start/stop/enable

systemctl — это инструмент для управления сервисами и системами запуска на основе systemd, который является дефолтным менеджером сервисов на большинстве современных дистрибутивов Linux. Команды start, stop, restart, reload позволяют управлять текущим состоянием сервисов, в то время как enable и disable обеспечивают автоматический запуск сервисов при загрузке системы. Команда status предоставляет информацию о текущем состоянии сервиса и выводит последние логи, что позволяет быстро диагностировать проблемы.

Как это работает

systemctl является фронтендом для управления systemd, который является дефолтным инициализатором и менеджером сервисов на большинстве современных дистрибутивов Linux. Для управления сервисами используются unit-файлы, которые находятся в директории /etc/systemd/system/. В этих файлах объявляются параметры, такие как ExecStart (путь к исполняемому файлу), User (пользователь, от имени которого запускается сервис), Restart-policy (политика перезапуска сервиса), а также зависимости (например, After= и Wants=).

Команды systemctl позволяют выполнять различные операции:

• systemctl start myapp — запускает сервис myapp.
• systemctl stop myapp — останавливает сервис myapp.
• systemctl restart myapp — перезапускает сервис myapp.
• systemctl status myapp — выводит текущее состояние сервиса и последние логи.
• systemctl enable myapp — создает симлинк, чтобы сервис запускался автоматически при загрузке системы.
• journalctl -u myapp — выводит логи сервиса myapp.

Также существуют различные типы unit-файлов:

• .service — основной тип для управления сервисами.
• .timer — альтернатива cron, позволяет выполнять задачи в определенное время.
• .socket — позволяет активировать сервис лениво (lazy activation).
• .target — используется для группировки сервисов.

Команда systemd-analyze позволяет оценить производительность загрузки системы, показывая время загрузки и узкие места.

Когда применять

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

Тип .timer лучше, чем cron, для новых заданий, так как он обеспечивает лучшее логирование и управление зависимостями. Для контейнеризованных нагрузок systemd может быть заменен оркестраторами, такими как Docker или Kubernetes. Не следует запускать systemd внутри обычного контейнера, если это не строго необходимо. Например, команда podman run --systemd существует для редких случаев, когда это действительно необходимо.

Типичные ошибки

При работе с systemctl могут возникать различные ошибки:

• Правка файлов в директории /lib/systemd/system/ может быть перезаписана при обновлении пакета. Вместо этого следует использовать директорию /etc/systemd/system/ или drop-in .d/ директории.
• Забытый systemctl daemon-reload после изменения unit-файлов может привести к тому, что изменения не будут применены.
• Политика Restart=always может привести к бесконечному циклу перезапуска сервиса, что может привести к высокой загрузке процессора и наводнению логов.
• Дефолтное удержание журналов journald может привести к быстрому заполнению диска. Для решения этой проблемы можно задать параметр SystemMaxUse= в файле конфигурации journald (/etc/systemd/journald.conf).

Связанные понятия

• systemd и службы
• Создание файлов-служб
• journalctl и фильтрация логов
• Цели и процесс загрузки
• Управление пользователями и группами
• Управление доступом к файлам
• Управление пакетами
• Управление процессами