Can’t open PID file /var/run/*.pid (yet?)

Иногда нарушается работа сервисов в Linux ошибкой

Can’t open PID file /var/run/*.pid (yet?)

Проблема может крыться как в правах на доступ к папке /var/run/ и процессорному pid файлу, так и в самом ядре системы Linux. Чтобы исключить проблему с правами перейдите в пользователя, от лица которого запускается сервис, и попробуйте открыть файл на чтение. Если он откроется без проблем, то можно искать проблему дальше.

Часто проблема с открытием таких файлов возникает при обновлении от очень старых (версии до 2.9) до более менее свежих (версии 3.10). К примеру, такое было у всех, кто пользовался CentOS седьмой версии с самого релиза. Дело в том, что начиная с версии ядра 3.10 был изменён способ работы символических ссылок. И если раньше сервисы работали с ссылкой "/var/run/" на папку "/run/" без проблем, то сейчас выдают ошибку "Too many levels of symbolic links". Очевидным выходном будет заменить все вхождения "/var/run/" на "/run/" в конфигурационных файлах сервисов.

Продемонстрируем на примере NGINX, который не просто не умеет работать с новыми ссылками, а вообще останавливает свою работу. Так что сайты становятся недоступны.

Поэтому откроем текстовым редактором и изменим место хранения PID файла NGINX с /var/run/nginx.pid на /run/nginx.pid в файлах /etc/nginx/nginx.conf и /lib/systemd/system/nginx.service

После такого изменения необходимо перезагрузить все демоны. То есть выполнить команду:

systemctl daemon-reload

Теперь можно перезапускать NGINX:

systemctl restart nginx

И через несколько минут надо проверить его статус (если pid файл не открылся, то NGINX остановится через минуту):

systemctl status nginx

Результат будет такой:

Active: active (running) since ....; 10m ago

Подобным образом восстанавливается работа не только NGINX, но и базы данных MySQL. К счастью, последняя не перестаёт работать после потери связи с PID файлов. Но для лечения необходимо всё так же изменить файл конфигурации как программы, так и самого демона в systemd.