status=200/CHDIR: systemd так и не запустил OpenVPN

Сервис падает, в журналах упоминаются spawn и каталог, и первым побуждением бывает проверить конфигурацию VPN. Из этого файла ещё ничего не прочитано. systemd потерпел неудачу при подготовке процесса, до запуска исполняемого файла, поэтому ни один парсер, ни один сертификат и ни один удалённый хост не были опрошены. Чтение кода состояния как утверждения о systemd, а не об OpenVPN, — это то, что делает дело коротким расследованием.

Прочитайте код состояния до приложения

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

Это различие важно, потому что исправления находятся в разных файлах. Ошибка CHDIR касается пути и того, как его видит сервис. Ошибка exec касается бинарного файла, его интерпретатора или несвязанного монтирования. Изменение удалённой точки VPN, списка шифров или пути к сертификату не исправит ни одну из них.

Убедитесь, что сбой происходит при запуске, а не после успешной работы. Если сервис работал вчера, а теперь падает на том же этапе, что-то изменилось в каталоге, его правах или самом unit, и это изменение — доказательство, которое нужно искать.

Спросите unit, где он хочет быть

Читайте действующий unit, а не файл, который вы считаете установленным, потому что drop-in могут переопределить рабочий каталог, так и не заставив вас править основной unit. Вывод show отвечает на вопрос напрямую:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

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

Сравните то, что требует unit, с тем, что существует. Путь, который когда-то был, символическая ссылка, теперь указывающая в другое место, или имя экземпляра, больше не соответствующее каталогу, — это обычные изменения, дающие именно этот сбой.

Проверьте путь так, как его видит сервис

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

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

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

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

Исправьте владельца, затем ждите другой ошибки

Исправьте раскладку или unit через того, кто владеет этой конфигурацией. Перемещение профиля в ожидаемый каталог — законное исправление, когда раскладка неверна, но оно не объясняет каталог, в который нельзя войти, поэтому не считайте его общим ответом.

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

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

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