После остановки сервиса остались worker: проверяем KillMode

systemctl stop завершился, основной PID исчез, а дочерние обработчики продолжают писать в каталог. Следующий запуск создаёт ещё одну группу, и две копии приложения мешают друг другу. Нужно проверить, какие процессы systemd считает частью службы и как именно выполняет остановку.

Зафиксировать границу сервиса

systemctl show worker.service -p MainPID -p ControlGroup -p KillMode -p TimeoutStopUSec
systemctl status worker.service
systemd-cgls /system.slice/worker.service
systemctl cat worker.service

Путь в systemd-cgls подставьте из ControlGroup. Посмотрите не только родительские PID, но и членство в cgroup. Обычное отделение от терминала не должно выводить ребёнка из группы службы. Если процесс запущен другой службой или перенесён в иную группу, правило остановки первой службы на него не распространяется.

Выбрать согласованную политику

В штатном KillMode=control-group остановка относится к процессам всей группы. KillMode=process затрагивает только основной процесс и может оставлять детей. Вариант mixed позволяет сначала передать сигнал основному процессу, а при последующем принудительном завершении охватить группу. Правила описаны в systemd.kill.

[Service]
KillMode=control-group
KillSignal=SIGTERM
TimeoutStopSec=45s

Это фрагмент конфигурации, а не команда для немедленного применения ко всем службам. Приложение должно корректно переживать SIGTERM у worker. Если основной процесс сам координирует прекращение заданий, сначала изучите его модель остановки. Изменение времени ожидания не создаёт обработчик сигнала в коде.

Проверить завершение работы

На стенде запустите несколько задач, затем остановите службу и наблюдайте журнал и cgroup. Хороший сценарий: новые задания перестают приниматься, текущие заканчиваются или сохраняют состояние, вся группа исчезает до истечения таймаута. Если процесс игнорирует сигнал, по завершении отведённого времени systemd обычно переходит к принудительному сигналу с учётом других настроек.

Не уменьшайте таймаут только ради быстрого stop. Для больших файлов и транзакций это может превращать корректную остановку в регулярный аварийный выход. Сравните длительность нескольких штатных завершений и определите допустимое окно. Проверьте также ExecStop: долгая или ошибочная вспомогательная команда влияет на процедуру.

Сравнить группу до и после stop

В учебном наблюдении до остановки cgroup содержит главный PID 6100 и обработчики 6105, 6106. При KillMode=process исчезает только 6100, а оставшиеся PID продолжают существовать в группе. Это объясняет, почему следующий start сталкивается с уже открытыми ресурсами. Сохраните такой снимок перед изменением.

После выбора control-group и нового запуска проверяйте уже новые PID. При штатном stop все три должны завершиться в отведённое время. Если 6105 заменился на новый 6205, это не «тот же процесс»: повторное создание может означать другой инициатор запуска. Проверяйте время старта и cgroup каждого оставшегося PID, чтобы не приписать службе чужого ребёнка.

Убрать повторное появление

После изменения сохраните drop-in и проверьте эффективную конфигурацию. daemon-reload перечитывает определения, но не доказывает поведение уже работающей программы. Полноценная проверка требует нового запуска и остановки в контролируемом окружении. Затем убедитесь, что повторный start создаёт ровно одну группу процессов-обработчиков.

В отчёте оставьте список процессов до stop и после него, длительность завершения и фрагмент журнала. Это отличает исправленную политику остановки от случайного исчезновения PID. Если оставшийся процесс оказался в другой службе, исправляйте источник его запуска, а не расширяйте kill до всех процессов с похожим именем.

Изучите программу Linux и Bash для DevOps-инженеров. В ней настройка systemd опирается на понимание процессов и журналов, что помогает проектировать запуск и остановку учебного сервиса как воспроизводимую процедуру.

Ещё по теме

• Сервис пропущен без ошибки: Condition и Assert в systemd
• Плохой конфиг не должен запускать сервис: добавляем ExecStartPre