No such process при остановке или сигнале
Сообщение No such process (номер 3, ESRCH) при остановке службы означает, что процесс уже завершился. Само по себе это не беда, но ненулевой код команды остановки помечает службу упавшей.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Команда остановки выполняется после завершения процесса
Процесс упал сам, а команда остановки попыталась послать ему сигнал. Служба помечается упавшей из-за завершающей команды.
-
Подстановка номера процесса пуста
Если служба не работает, подстановка даёт пустую строку. Команда получает неверный аргумент.
-
Номер процесса взят из устаревшего файла
Команда останова читает pid-файл, а процесс с этим номером уже не существует.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Какая команда вернула ошибку.
systemctl status myapp.service -l --no-pager | grep "Process:"Номер процесса и команда остановки.
systemctl show myapp.service -p MainPID -p ExecStopРешение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Процесс упал сам, а команда остановки попыталась послать ему сигнал. Служба помечается упавшей из-за завершающей команды.
- Как проверить
-
Посмотрите, какая команда вернула ошибку.
systemctl status myapp.service -l --no-pager | grep -E "Process:|Active:"
- Как исправить
-
Сделайте команду остановки терпимой: поставьте дефис перед ней или объявите код успешным. Это убирает ложный сбой.
ExecStop=-/bin/kill -TERM $MAINPID
- Почему происходит
- Если служба не работает, подстановка даёт пустую строку. Команда получает неверный аргумент.
- Как проверить
-
Посмотрите номер процесса и команду.
systemctl show myapp.service -p MainPID -p ExecStop
- Как исправить
- Используйте команды, работающие и при остановленной службе, либо полагайтесь на сигналы systemd вместо своей команды остановки.
- Почему происходит
- Команда останова читает pid-файл, а процесс с этим номером уже не существует.
- Как проверить
-
Посмотрите файл и процессы.
cat /run/myapp.pid 2>/dev/null; ps -p "$(cat /run/myapp.pid 2>/dev/null)" 2>/dev/null || echo "процесса нет"
- Как исправить
- Уберите зависимость от pid-файла: systemd знает главный процесс сам.
Пример вывода
Команда остановки не нашла процесс. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
× myapp.service - My application
Process: 4400 ExecStop=/bin/kill -TERM 1200 (code=exited, status=1/FAILURE)
kill[4400]: kill: (1200): No such process
systemd[1]: myapp.service: Control process exited, code=exited, status=1/FAILUREСвязанные ошибки
- status=7/NOTRUNNING в systemd Код 7/NOTRUNNING по соглашению LSB: программа не запущена. Обычно приходит от ExecStop или ExecReload, а не от запуска.
- Устаревший pid-файл мешает запуску Служба считает, что уже работает: остался pid-файл после аварийного завершения.
- signal=TERM (status=15/TERM) в systemd Процесс службы завершён сигналом TERM. Когда это нормальная остановка, а когда признак проблемы.
- Target is busy: точка монтирования занята Не удаётся отмонтировать: target is busy. Как найти процессы, которые держат точку монтирования, и корректно освободить её.
- Too many tasks: упор в предел TasksMax Служба не может создать новый процесс: достигнут предел TasksMax. Где он задан и как поднять правильно.
- signal=INT и signal=QUIT в systemd Процесс службы завершён сигналом INT или QUIT. Кто их посылает службам и почему это обычно не systemd.
- signal=KILL (status=9/KILL) в systemd Процесс службы убит сигналом KILL. Кто мог его послать: OOM-killer, таймаут остановки systemd, администратор.
- supervisord под systemd: два надзорщика за одними процессами Процессы перезапускаются дважды или не перезапускаются вовсе: systemd и supervisord следят за одним и тем же.
Источники
- kill(2): ошибка ESRCH
-
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено командой остановки после самостоятельного падения процесса.