SystemdDoctor
служба не работает запуск pidfile

Устаревший pid-файл мешает запуску

Программы, управляемые pid-файлом, при запуске проверяют его наличие. Файл, оставшийся после аварийного завершения, заставляет их думать, что экземпляр уже работает — и запуск не проходит.

Вероятные причины

По порядку: сверху то, что встречается чаще.

  1. Файл остался после аварийного завершения

    При убийстве процесса сигналом KILL файл не удаляется. Следующий запуск видит его и отказывается.

  2. Номер процесса занят другой программой

    Номера переиспользуются. Устаревший файл может указывать на постороннюю программу, и проверка решит, что служба работает.

  3. Путь файла не совпадает с параметром unit

    Если PIDFile= указывает не туда, где программа создаёт файл, systemd теряет процесс и считает службу упавшей.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Путь файла и номер процесса по мнению systemd.

systemctl show myapp.service -p PIDFile -p MainPID

Существует ли процесс из файла.

ps -p "$(cat /run/myapp.pid 2>/dev/null)" 2>/dev/null || echo "процесса нет"

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Файл остался после аварийного завершения
Почему происходит
При убийстве процесса сигналом KILL файл не удаляется. Следующий запуск видит его и отказывается.
Как проверить
Проверьте, есть ли процесс с этим номером. 
cat /run/myapp.pid 2>/dev/null
ps -p "$(cat /run/myapp.pid 2>/dev/null)" 2>/dev/null || echo "процесса нет"
Как исправить
Удалите устаревший файл и запустите службу. Чтобы это не повторялось, положите файл в каталог, который systemd очищает: объявите RuntimeDirectory=.
2. Номер процесса занят другой программой
Почему происходит
Номера переиспользуются. Устаревший файл может указывать на постороннюю программу, и проверка решит, что служба работает.
Как проверить
Посмотрите, чей это процесс. 
ps -p "$(cat /run/myapp.pid 2>/dev/null)" -o pid,comm,args 2>/dev/null
Как исправить
Удалите файл. Такой случай — хороший повод отказаться от pid-файлов: systemd следит за процессами сам.
3. Путь файла не совпадает с параметром unit
Почему происходит
Если PIDFile= указывает не туда, где программа создаёт файл, systemd теряет процесс и считает службу упавшей.
Как проверить
Сравните путь в unit и фактический файл. 
systemctl show myapp.service -p PIDFile
sudo ls -l /run/*.pid | head
Как исправить
Приведите пути к одному значению или откажитесь от демонизации: тип simple не требует pid-файла вовсе.

Пример вывода

Файл остался от убитого процесса. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

myapp[4400]: error: another instance is already running (pid 1200)

$ cat /run/myapp.pid
1200
$ ps -p 1200
  PID TTY      TIME CMD
# процесса нет

Связанные ошибки

Источники

  • systemd.service(5)
    PIDFile= и слежение за процессом.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено убийством процесса сигналом KILL с оставшимся pid-файлом.     собственная проверка, systemd 255
    сверено 15 сентября 2026