ExecStartPre= и ExecStartPost=: команды до и после запуска
Задаёт команды, которые выполняются до запуска главного процесса (ExecStartPre=) и после того, как служба признана запущенной (ExecStartPost=).
Что делает
Команды выполняются по порядку, и неудача любой из них отменяет запуск службы: главный процесс не будет вызван вовсе. Именно поэтому в статусе иногда видно Control process exited с кодом от проверки конфигурации, а не от самой программы — так устроены unit-файлы nginx и haproxy.
Полезное применение — проверка условий и подготовка: проверить конфигурацию, создать каталог, дождаться доступности зависимости. Не стоит выносить туда долгие операции: они входят в общий таймаут запуска.
Где ставится. В секции [Service], можно указывать несколько строк — выполняются в порядке объявления.
Значения
| Значение | Что происходит |
|---|---|
ExecStartPre=/usr/sbin/nginx -t | проверка конфигурации: при неудаче служба не запускается. |
ExecStartPre=-/bin/rm -f /run/app.lock | дефис делает неудачу несущественной: файла может и не быть. |
ExecStartPost=/usr/local/bin/notify-deploy | выполняется после того, как служба признана запущенной. |
Пример
Подготовка каталога и проверка настроек до запуска.
[Service]
ExecStartPre=-/bin/mkdir -p /var/lib/myapp/tmp
ExecStartPre=/usr/local/bin/myapp --check-config
ExecStart=/usr/local/bin/myapp --serve
ExecStartPost=/bin/sh -c 'echo запущено >> /var/log/myapp/deploy.log'Создание каталогов лучше делать не командой, а параметрами StateDirectory= и RuntimeDirectory=: systemd сделает это сам и с правильным владельцем.
Типичные ошибки
Неудача предварительной команды отменяет запуск целиком. Если команда необязательна, ставьте перед ней дефис.
Долгие предварительные команды съедают таймаут запуска: TimeoutStartSec= считается на всю последовательность.
ExecStartPost= выполняется после признания службы запущенной, а не после её фактической готовности. При Type=simple это почти сразу, и проверять там доступность службы бессмысленно.
В этих командах, как и в ExecStart=, нет оболочки: конвейер требует явного /bin/sh -c.
Связанные ошибки
- status=1/FAILURE в systemdКод 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
- Failed with result 'exit-code'Состояние exit-code: служба завершилась с ненулевым кодом. Что это сообщение значит и где искать настоящую причину.
- nginx: [emerg] unknown directivenginx не запускается: неизвестная директива в конфигурации. Опечатка, не тот контекст или отсутствующий модуль.
Рядом стоящие параметры
Где важен на практике
Источники
- systemd.service(5)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)