Многие администраторы и разработчики до сих пор изменяют unit-файлы напрямую в:
/usr/lib/systemd/system/
или:
/lib/systemd/system/
Но это vendor unit-файлы, устанавливаемые пакетным менеджером. После обновления пакета изменения могут быть перезаписаны.
Правильный способ настройки сервисов в systemd — использовать override-конфигурации через:
systemctl edit
Например, добавим переменные окружения для
nginx:sudo systemctl edit nginx.service
После сохранения
systemd создаст файл:/etc/systemd/system/nginx.service.d/override.conf
Это безопасный способ переопределения параметров сервиса без изменения оригинального unit-файла.
Пример добавления переменных окружения:
[Service]
Environment="APP_ENV=production"
Environment="WORKERS=4"
После сохранения
systemctl edit обычно автоматически выполняет daemon-reload, поэтому достаточно просто перезапустить сервис:sudo systemctl restart nginx
Если unit-файлы или override-конфигурации изменялись вручную в
/etc/systemd/system/, тогда дополнительно выполняют:sudo systemctl daemon-reload
Проверить итоговую конфигурацию сервиса можно так:
systemctl cat nginx.service
Команда покажет: оригинальный unit-файл, все override-конфигурации, порядок применения настроек.
А для просмотра итоговых параметров сервиса полезно использовать:
systemctl show nginx.service
Это особенно полезно при диагностике сложных production-конфигураций.
Переопределение
ExecStart, один из важных нюансов systemd — перед новым ExecStart старое значение нужно очистить. Пример:sudo systemctl edit app.service
Override:
[Service]
ExecStart=
ExecStart=/usr/local/bin/app --port 8080
Пустой
ExecStart= сбрасывает предыдущее значение из исходного unit-файла. Без очистки systemd может выдать ошибку, поскольку для сервисов с типом, отличным от Type=oneshot, допускается только один ExecStart.Автоматический перезапуск сервиса. Для production-сервисов часто настраивают автоматический перезапуск:
[Service]
Restart=on-failure
RestartSec=5
Так
systemd будет автоматически перезапускать сервис только при ошибках, а не после штатной остановки.Systemd умеет ограничивать ресурсы процессов через cgroup. Пример ограничения памяти:[Service]
MemoryMax=1G
Это особенно полезно для Node.js, Python, Java и других серверных приложений с непредсказуемым потреблением памяти.
Иногда требуется изменить почти весь unit-файл. Для этого используется:
sudo systemctl edit --full app.service
В этом режиме
systemd создаёт полный локальный unit-файл в:/etc/systemd/system/
который заменяет оригинальный unit из пакета.
Но использовать
--full стоит осторожно — после этого вы фактически берёте поддержку unit-файла на себя и можете пропустить изменения из новых версий пакета.Практический пример настройки сервиса:
[Service]
Environment="NODE_ENV=production"
WorkingDirectory=/srv/app
ExecStart=
ExecStart=/usr/bin/node /srv/app/server.js
Restart=on-failure
RestartSec=5
LimitNOFILE=65535
MemoryMax=1G
Так часто настраивают production-сервисы для Node.js, Go, Python, Java и других серверных приложений.
Дополнительно полезно знать:
systemctl show app.service -p FragmentPath -p DropInPaths
Команда покажет: путь к основному unit-файлу, все подключённые override-конфигурации.
🔥 Это стандартный и рекомендуемый способ настройки
systemd без риска потерять изменения после обновления системы.🚪 Linux Ready | #практика