Юнит -.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, сначала прочитайте имя юнита в сообщении, а потом имя службы.