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. Зразок, який варто запам'ятати, простий: кожен код стану називає інший етап, і лише власні помилки застосунку описують застосунок.