A -.mount egység maszkolt: az OpenVPN kliens nem indul el
Egy ott maradt -.mount fájl a /run/systemd/system mappában elmaszkolja a gyökér csatolási egységet, ezért minden egység, amelynek a fájlrendszerre szüksége van, elbukik, mielőtt az OpenVPN elindulna.
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.