Файл PID есть, туннеля нет: запускался ли OpenVPN вообще?

Когда программа запуска отказывается стартовать OpenVPN, потому что файл PID уже существует, естественное прочтение — где-то работает туннель. Это прочтение ошибочно достаточно часто, чтобы его стоило проверить, прежде чем что-либо удалять. Файл в каталоге выполнения — это учёт, а учёт переживает падения, перезагрузки и прерванные остановки, не оставившие процесса. Дело решают два вопроса: есть ли живой процесс и принадлежит ли он этому экземпляру.

Начинайте со службы, а не с файла

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

Прочитайте юнит или скрипт, напечатавший сообщение, и отметьте три вещи: проверяемый путь, объявляемый тип службы и то, отвечает ли он вообще за запись файла. Современный юнит может использовать простой надзор или надзор через уведомления и никогда не касаться файла PID, тогда как старый init-скрипт может создать его сам. Копирование проверки из одной модели в другую даёт ровно такой отказ. Выясните, какая модель используется, прежде чем что-либо толковать.

Только тогда вопрос становится таким: действительно ли работает экземпляр.

Проверьте, принадлежит ли этот идентификатор вашему экземпляру

Число в файле доказывает, что число было записано. Оно не доказывает, что процесс с этим идентификатором существует сейчас, и уж точно не доказывает, что процесс ваш, потому что идентификаторы повторно используются после перезагрузки.

Сравните время запуска процесса с отметкой времени файла, исполняемый файл с командой юнита, а членство в службе с именем юнита. Несовпадение в любом из трёх означает, что вы смотрите на учёт, а не на туннель.

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

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Что программа запуска обещала сделать с файлом

PIDFile= сообщает менеджеру служб, откуда читать идентификатор основного процесса. Менеджер не пишет этот файл, но удаляет оставшийся после остановки, и именно поэтому прерванный выход может оставить файл.

Это разделение ответственности объясняет два симптома, которые люди сообщают как ошибки. Файл, который никогда не появляется, означает, что демон или его скрипт не смогли его записать, а не то, что надзор настроен неверно. Файл, переживающий остановку, означает, что путь остановки так и не завершился.

Это также объясняет, почему текущие рекомендации советуют избегать соглашения, когда надзор может напрямую отслеживать основной процесс. Эти рекомендации не являются разрешением менять тип упакованного юнита, потому что поведение демона на переднем плане, при ветвлении или при уведомлении должно соответствовать тому, что объявляет юнит. Измените тип, не меняя демон, и вы получите юнит, который сообщает об ошибке, пока туннель работает, или наоборот. Согласуйте пару или оставьте оба. Справочник службы systemd описывает это разделение владения.

Чистая остановка против прерванного выхода

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

Сравните отметку времени файла с последней загрузкой и с последней остановкой юнита.

Затем проверьте живые свидетельства напрямую. Сокет, привязанный к порту VPN, и туннельный интерфейс с адресом — доказательство того, что что-то работает, так, как текстовый файл в каталоге выполнения не бывает никогда. Если нет ни того, ни другого, ничего не работает, что бы ни утверждал файл.

Перестаньте удалять файл по привычке

Удаление — законный шаг восстановления после того, как вы установили, что ни один экземпляр им не владеет и что программа запуска документирует такое поведение.

Как постоянная привычка перед запуском это обесценивает проверку, которую вы обходите. Если устаревшие файлы возвращаются после каждой чистой остановки, писатель и жизненный цикл остановки расходятся в том, кому принадлежит путь, и это расхождение — ошибка, которую стоит исправить.

Держите независимый путь на хост, запустите один экземпляр через его обычный менеджер и прочитайте первый результат. Следующий человек получит юнит, который либо работает, либо объясняет себя.