A szolgáltatásod még azelőtt elbukik, hogy OpenVPN egyáltalán lefutna, a hiba pedig egy olyan csatolási egységről beszél, amelyet soha nem állítottál be. Ez a nyom: a systemd az egész tranzakciót elutasítja, mert a gyökér csatolási egység maszkolt, és a VPN-profilodat még nem is olvasta be. A szokásos ok egy ott maradt fájl a futásidejű egységek könyvtárában, nem egy törött fstab és nem egy hiányzó tanúsítvány. Először a fájlt kövesd, mert ezt a legolcsóbb kizárni.

A hiba a gyökér csatolást nevezi meg, nem a profilodat

A systemd maga állítja elő a gyökér csatolási egységet a kernel csatolási információiból, és -.mount néven nevezi el, mert a kötőjel a gyökérútvonalat jelöli. Ez az egység általában csak a memóriában létezik, és nincs mögötte fájl. Amikor a hiba azt mondja, hogy maszkolt, valami betett egy egységfájlt oda, ahonnan a systemd betölti, és ezt a fájlt /dev/null-ra irányította. A maszk valódi állapot, nem elírás az üzenetben.

A példányegység azért bukik el, mert a feladatgráfja a sorrendezésen és a saját csatolási követelményein keresztül eléri a gyökér csatolást. A tranzakciót még az OpenVPN binárisának végrehajtása előtt elutasítják, tehát a kliens beállításaiban semmi nem lehet az ok. Ezért a profilok, tanúsítványok vagy hitelesítő adatok cseréje nincs hatással erre a konkrét hibára.

Nézd meg a futásidejű könyvtárat, mielőtt az OpenVPN-t hibakeresnéd

Keress egy pontosan ilyen nevű fájlt a futásidejű egységek könyvtárában, majd kérdezd meg a systemd-t, mit gondol az egységről. Mindkét válasz gyors, és együtt elválasztja az ott maradt fájlt egy valódi csatolási problémától.

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

Egy normál gépen nincs ilyen fájl, és a maszkoltak listája nem tartalmazza a gyökér csatolást. Ha az első parancs egy szimbolikus hivatkozást ír ki /dev/null-ra, a diagnózis megvan. Ugyanabban a könyvtárban lehet egy tmp.mount maszk is, amelyet ugyanazok az eszközök hoztak létre, és ez ugyanazt a hibaosztályt okozza más néven. Nézd meg az egész könyvtárat, ne csak a hibában szereplő nevet.

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

Ha a könyvtár tiszta, és az egység még mindig maszkolt, a maszk a keresési útvonal más helyén van, és a systemctl cat -.mount megmutatja, melyik fájl töltődik be.

Töröld a fájlt, töltsd újra és indítsd újra

Elég a futásidejű fájlt eltávolítani és a kezelőt újratölteni, és ez semmihez nem nyúl, ami csomagból származik. Indítás előtt töltsd újra, mert a systemd megtartja a betöltött egység állapotát, amíg újra nem olvassa a könyvtárat.

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

Ezután olvasd el a szolgáltatás saját naplóját, ahelyett hogy feltételeznéd, hogy a javítás működött. A tiszta indítás csak azt bizonyítja, hogy a systemd elfogadta az egységet; a kliens továbbra is elhalhat egy hiányzó profilon, egy elérhetetlen peeren vagy egy nem érvényesülő tanúsítványon. Ezek szokásos OpenVPN-problémák, amelyek a maszkolt egység mögött rejtőztek. A napló rögzíti, melyik profil töltődött be, és hogy az alagút valóban felépült-e. Ha az egység elindul és az alagút nem, akkor más problémához jutottál, ami előrelépés.

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

Mivel a /run ideiglenes fájlrendszer, az újraindítás a fájlt is törli. Ez hasznos tesztté teszi az újraindítást: ha a szolgáltatás újraindítás után működik, a következő telepítés után pedig újra elbukik, akkor a fájl bele van sütve a képbe.

Akadályozd meg, hogy visszajöjjön a képből

Egy konténer- vagy virtuálisgép-sablon, amely a build során maszkolja a csatolási egységeket, továbbviszi ezt a maszkot minden klónba. A következő dolog, aminek a fájlrendszerre szüksége van, eltörik, és az üzenet a csatolást hibáztatja a kép helyett, ahonnan jött. Egy futó példányon belüli javítás elrejti a problémát a következő példány létrehozásáig.

Keresd meg a build környezetében a fájlnevet és az őt létrehozó parancsot, majd távolítsd el a maszkot a sablonból és építsd újra. Ha a maszkra a build során valóban szükség van, abban a rétegben távolítsd el, amely befejezi a buildet, hogy a kiszállított kép tisztán induljon. Friss klónon ellenőrizd, ne a gépen, amelyet kézzel javítottál. Ez az egyetlen teszt, amely bizonyítja, hogy a kép megváltozott.

A megjegyzendő tünet a hiba és a beállított dolog közötti eltérés. Amikor a systemd egy csatolásra panaszkodik, miközben VPN-klienst indítasz, előbb az üzenetben szereplő egységnevet olvasd el, és csak utána a szolgáltatás nevét.

Kapcsolódó cikkek