Юніт -.mount замасковано: клієнт OpenVPN не запускається

Ваша служба падає ще до того, як OpenVPN взагалі запуститься, а помилка говорить про юніт монтування, який ви ніколи не налаштовували. Це і є ознака: systemd відхиляє всю транзакцію, бо юніт коренового монтування замасковано, а ваш профіль VPN ще не прочитано. Звичайна причина — залишений файл у каталозі юнітів часу виконання, а не зламаний fstab і не відсутній сертифікат. Спершу перевірте файл, бо це найдешевше пояснення, яке можна виключити.

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

systemd сам створює юніт коренового монтування з відомостей про монтування ядра і називає юніт -.mount, бо дефіс позначає кореневий шлях. Цей юніт зазвичай існує лише в пам'яті і за ним немає файлу. Коли помилка каже, що його замасковано, хтось поклав файл юніта туди, звідки systemd його завантажить, і спрямував цей файл на /dev/null. Маскування — реальний стан, а не друкарська помилка в повідомленні.

Юніт екземпляра падає, бо його граф завдань досягає коренового монтування через упорядкування і через власні вимоги до монтування. Транзакцію відхилено до запуску бінарника OpenVPN, тому ніщо в конфігурації клієнта не може бути причиною. Тому зміна профілів, сертифікатів чи облікових даних не впливає на цей конкретний збій.

Загляньте в каталог часу виконання, перш ніж налагоджувати OpenVPN

Пошукайте файл з точно такою назвою в каталозі юнітів часу виконання, потім запитайте в systemd, чим він вважає цей юніт. Обидві відповіді швидкі, і разом вони відділяють залишений файл від справжньої проблеми з монтуванням.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

На звичайній машині такого файлу немає, і список замаскованих не містить коренового монтування. Якщо перша команда виводить символічне посилання на /dev/null, діагноз встановлено. У тому самому каталозі може бути маска tmp.mount, створена тими самими інструментами, і вона дає той самий клас збою під іншою назвою. Дивіться на весь каталог, а не лише на назву з помилки.

ls -la /run/systemd/system/*.mount

Якщо каталог чистий, а юніт усе ще замасковано, маска розташована в іншому місці шляху пошуку, і systemctl cat -.mount покаже, який файл завантажується.

Видаліть файл, перезавантажте і запустіть знову

Достатньо прибрати файл часу виконання і перезавантажити менеджер, і це не торкається нічого з пакета. Перезавантажте перед запуском, бо systemd зберігає стан завантаженого юніта, доки не перечитає каталог.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

Потім прочитайте журнал самої служби замість того, щоб припускати, що виправлення спрацювало. Чистий запуск доводить лише те, що systemd прийняв юніт; клієнт усе ще може загинути через відсутній профіль, недосяжного партнера або сертифікат, який не проходить перевірку. Це звичайні проблеми OpenVPN, які були приховані за замаскованим юнітом. Журнал фіксує, який профіль завантажено і чи тунель справді було встановлено. Якщо юніт запускається, а тунель ні, ви перейшли до іншої проблеми, і це прогрес.

journalctl -u [email protected] -b --no-pager

Оскільки /run — тимчасова файлова система, перезавантаження також видаляє файл. Це робить перезавантаження корисною перевіркою: якщо служба працює після перезавантаження і знову падає після наступного розгортання, файл запікається в образ.

Не дайте йому повернутися з образу

Шаблон контейнера або віртуальної машини, який маскує юніти монтування під час збирання, перенесе цю маску в кожен клон. Наступне, що потребує файлової системи, зламається, і повідомлення звинувачує монтування, а не образ, з якого воно прийшло. Виправлення всередині одного працюючого екземпляра приховує проблему до створення наступного екземпляра.

Пошукайте в контексті збирання назву файлу і команду, що його створює, потім приберіть маску з шаблону і зберіть знову. Якщо маска справді потрібна під час збирання, приберіть її в тому самому шарі, який завершує збирання, щоб образ, який постачається, стартував чистим. Перевірте на свіжому клоні, а не на машині, яку ви полагодили вручну. Це єдина перевірка, що доводить зміну образу.

Симптом, який варто запам'ятати, — невідповідність між помилкою і тим, що ви налаштовували. Коли systemd скаржиться на монтування, поки ви запускаєте клієнт VPN, спершу прочитайте назву юніта в повідомленні, а потім назву служби.