Работа с systemctl edit — переопределение systemd unit без изменения оригинального файла!Многие администраторы и разработчики до сих пор изменяют 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 | #практика 
