-.mount-enheden er maskeret: OpenVPN-klienten starter ikke
En overskydende -.mount-fil i /run/systemd/system maskerer rodens monteringsenhed, så enhver enhed, der har brug for filsystemet, fejler, før OpenVPN starter.
Din tjeneste fejler, før OpenVPN overhovedet kører, og fejlen taler om en monteringsenhed, du aldrig har konfigureret. Det er tegnet: systemd afviser hele transaktionen, fordi rodens monteringsenhed er maskeret, og din VPN-profil er ikke blevet læst endnu. Den sædvanlige årsag er en efterladt fil i runtime-enhedsmappen, ikke en ødelagt fstab og ikke et manglende certifikat. Følg filen først, for det er den billigste forklaring at udelukke.
Fejlen nævner rodens montering, ikke din profil
systemd genererer selv rodens monteringsenhed ud fra kernens monteringsoplysninger og kalder enheden -.mount, fordi en bindestreg står for rodstien. Den enhed findes normalt kun i hukommelsen og har ingen fil bag sig. Når fejlen siger, at den er maskeret, har nogen lagt en enhedsfil, hvor systemd vil indlæse den, og peget filen mod /dev/null. Masken er en reel tilstand, ikke en tastefejl i meddelelsen.
Instansens enhed fejler, fordi dens jobgraf når rodens montering gennem rækkefølge og gennem sine egne monteringskrav. Transaktionen afvises, før OpenVPN-binæren køres, så intet i klientens konfiguration kan være årsagen. Derfor har ændrede profiler, certifikater eller legitimationsoplysninger ingen virkning på netop denne fejl.
Kig i runtime-mappen, før du fejlfinder OpenVPN
Led efter en fil med præcis det navn i runtime-enhedsmappen, og spørg derefter systemd, hvad den mener, enheden er. Begge svar er hurtige, og sammen skiller de en efterladt fil fra et egentligt monteringsproblem.
ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount
En normal maskine har ingen sådan fil, og den maskerede liste indeholder ikke rodens montering. Hvis den første kommando udskriver et symbolsk link til /dev/null, er diagnosen afgjort. Den samme mappe kan indeholde en tmp.mount-maske oprettet af de samme værktøjer, og det giver samme slags fejl under et andet navn. Se på hele mappen i stedet for kun navnet i fejlen.
ls -la /run/systemd/system/*.mount
Hvis mappen er ren, og enheden stadig er maskeret, ligger masken et andet sted i søgestien, og systemctl cat -.mount viser, hvilken fil der indlæses.
Slet filen, genindlæs og start igen
Det er nok at fjerne runtime-filen og genindlæse manageren, og det rører intet, der kom fra en pakke. Genindlæs før start, fordi systemd beholder den indlæste enhedstilstand, indtil den læser mappen igen.
sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]
Læs derefter tjenestens egen journal i stedet for at antage, at rettelsen virkede. En ren start beviser kun, at systemd accepterede enheden; klienten kan stadig dø på en manglende profil, en uopnåelig peer eller et certifikat, der ikke validerer. Det er almindelige OpenVPN-problemer, som var skjult bag den maskerede enhed. Den registrerer, hvilken profil der blev indlæst, og om tunnelen faktisk blev etableret. Hvis enheden starter og tunnelen ikke gør, er du gået videre til et andet problem, og det er fremskridt.
journalctl -u [email protected] -b --no-pager
Fordi /run er et midlertidigt filsystem, rydder en genstart også filen. Det gør en genstart til en nyttig test: hvis tjenesten virker efter en genstart og fejler igen efter næste udrulning, bliver filen bagt ind i imaget.
Forhindr, at den kommer tilbage fra imaget
En container- eller virtuelmaskine-skabelon, der maskerer monteringsenheder under sit build, tager den maske med til hver klon. Det næste, der har brug for filsystemet, går i stykker, og meddelelsen giver monteringen skylden i stedet for det image, den kom fra. At rette det inde i én kørende instans skjuler problemet, indtil den næste instans oprettes.
Søg i build-konteksten efter filnavnet og efter kommandoen, der opretter det, fjern derefter masken fra skabelonen, og byg igen. Hvis masken virkelig er nødvendig under build, skal du fjerne den i det samme lag, der afslutter build, så det leverede image starter rent. Bekræft på en frisk klon i stedet for på den maskine, du har repareret i hånden. Det er den eneste test, der beviser, at imaget er ændret.
Det symptom, du skal huske, er uoverensstemmelsen mellem fejlen og det, du konfigurerede. Når systemd klager over en montering, mens du starter en VPN-klient, så læs enhedsnavnet i meddelelsen, før du læser tjenestenavnet.