Вашата услуга паѓа пред OpenVPN воопшто да се стартува, а грешката зборува за единица за монтирање што никогаш не сте ја поставиле. Тоа е знакот: systemd ја одбива целата трансакција затоа што единицата за коренско монтирање е маскирана, а вашиот VPN профил сѐ уште не е прочитан. Обичната причина е преостаната датотека во директориумот за runtime единици, а не расипан fstab и не сертификат што недостасува. Прво следете ја датотеката, зашто тоа е најевтиното објаснување што може да се исклучи.

Грешката го именува коренското монтирање, не вашиот профил

systemd сам ја создава единицата за коренско монтирање од податоците за монтирање на јадрото и ја нарекува единицата -.mount затоа што цртичката го означува коренскиот пат. Таа единица обично постои само во меморија и нема датотека зад себе. Кога грешката вели дека е маскирана, некој ставил датотека за единица таму каде што systemd ќе ја вчита и ја насочил датотеката кон /dev/null. Маскирањето е вистинска состојба, а не печатна грешка во пораката.

Единицата на инстанцата паѓа затоа што нејзиниот граф на задачи стигнува до коренското монтирање преку редослед и преку сопствените барања за монтирање. Трансакцијата се одбива пред да се изврши бинарната датотека на OpenVPN, па ништо во конфигурацијата на клиентот не може да биде причина. Затоа промената на профили, сертификати или акредитиви нема ефект врз овој конкретен дефект.

Погледнете го runtime директориумот пред да го дебагирате OpenVPN

Барајте датотека со точно тоа име во директориумот за runtime единици, потоа прашајте го 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 ќе покаже која датотека се вчитува.

Избришете ја датотеката, вчитајте повторно и стартувајте повторно

Доволно е да се отстрани runtime датотеката и да се вчита менаџерот повторно, и тоа не допира ништо што доаѓа од пакет. Вчитајте повторно пред стартување, затоа што 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 клиент, прво прочитајте го името на единицата во пораката, а потоа името на услугата.

Поврзани статии