Eenheid -.mount is gemaskeerd: OpenVPN-client start niet

Je dienst mislukt voordat OpenVPN ooit draait, en de fout spreekt over een mounteenheid die je nooit hebt geconfigureerd. Dat is het teken: systemd weigert de hele transactie omdat de root-mounteenheid is gemaskeerd, en je VPN-profiel is nog niet gelezen. De gebruikelijke oorzaak is een achtergebleven bestand in de map voor runtime-eenheden, niet een kapotte fstab en niet een ontbrekend certificaat. Volg eerst het bestand, want dat is de goedkoopste verklaring om uit te sluiten.

De fout noemt de root-mount, niet je profiel

systemd genereert de root-mounteenheid zelf uit de mountinformatie van de kernel, en noemt de eenheid -.mount omdat een streepje voor het rootpad staat. Die eenheid bestaat normaal alleen in het geheugen en heeft geen bestand erachter. Als de fout zegt dat ze is gemaskeerd, heeft iets een eenheidsbestand neergezet waar systemd het laadt, en dat bestand naar /dev/null laten wijzen. De maskering is een echte toestand, geen tikfout in de melding.

De instantie-eenheid mislukt omdat zijn taakgraaf de root-mount bereikt via ordening en via zijn eigen mountvereisten. De transactie wordt geweigerd voordat het OpenVPN-programma wordt uitgevoerd, dus niets in de configuratie van de client kan de oorzaak zijn. Daarom heeft het wisselen van profielen, certificaten of inloggegevens geen effect op deze specifieke fout.

Kijk in de runtimemap voordat je OpenVPN gaat debuggen

Zoek een bestand met precies die naam in de map voor runtime-eenheden en vraag systemd dan wat hij denkt dat de eenheid is. Beide antwoorden zijn snel, en samen scheiden ze een achtergebleven bestand van een echt mountprobleem.

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

Een normale machine heeft zo'n bestand niet, en de gemaskeerde lijst bevat de root-mount niet. Als de eerste opdracht een symbolische koppeling naar /dev/null afdrukt, is de diagnose rond. Dezelfde map kan een tmp.mount-maskering bevatten die door hetzelfde gereedschap is gemaakt, en dat levert dezelfde klasse fout op onder een andere naam. Kijk naar de hele map en niet alleen naar de naam in de fout.

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

Als de map schoon is en de eenheid nog steeds is gemaskeerd, zit de maskering elders in het zoekpad, en systemctl cat -.mount laat zien welk bestand wordt geladen.

Verwijder het bestand, herlaad en start opnieuw

Het runtimebestand verwijderen en de beheerder herladen is genoeg, en het raakt niets dat uit een pakket komt. Herlaad voordat je start, want systemd houdt de geladen toestand van de eenheid tot het de map opnieuw leest.

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

Lees daarna het journaal van de dienst zelf in plaats van aan te nemen dat de reparatie werkte. Een schone start bewijst alleen dat systemd de eenheid accepteerde; de client kan nog steeds sterven op een ontbrekend profiel, een onbereikbare peer of een certificaat dat niet valideert. Dat zijn gewone OpenVPN-problemen die achter de gemaskeerde eenheid verborgen zaten. Het journaal legt vast welk profiel werd geladen en of de tunnel echt tot stand kwam. Als de eenheid start en de tunnel niet, ben je naar een ander probleem doorgeschoven, en dat is vooruitgang.

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

Omdat /run een tijdelijk bestandssysteem is, ruimt een herstart het bestand ook op. Dat maakt een herstart een nuttige test: als de dienst na een herstart werkt en na de volgende uitrol weer faalt, wordt het bestand in de image gebakken.

Voorkom dat het uit de image terugkomt

Een container- of virtuelemachine-sjabloon dat tijdens de build mounteenheden maskeert, draagt die maskering naar elke kloon. Wat daarna het bestandssysteem nodig heeft, breekt, en de melding geeft de mount de schuld in plaats van de image waar hij vandaan komt. Repareren binnen één draaiende instantie verbergt het probleem tot de volgende instantie wordt gemaakt.

Zoek in de buildcontext naar de bestandsnaam en naar de opdracht die hem maakt, haal dan de maskering uit het sjabloon en bouw opnieuw. Is de maskering tijdens de build echt nodig, verwijder hem dan in dezelfde laag die de build afrondt, zodat de verzonden image schoon start. Controleer op een verse kloon en niet op de machine die je met de hand hebt gerepareerd. Dat is de enige test die bewijst dat de image is veranderd.

Het symptoom om te onthouden is de mismatch tussen de fout en het ding dat je aan het configureren was. Als systemd klaagt over een mount terwijl je een VPN-client start, lees dan de eenheidsnaam in de melding voordat je de dienstnaam leest.