Юнитът -.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 клиент, прочетете името на юнита в съобщението, преди да прочетете името на услугата.