Unitatea -.mount este mascată: clientul OpenVPN nu pornește
Un fișier -.mount rămas în /run/systemd/system maschează unitatea de montare rădăcină, așa că fiecare unitate care are nevoie de sistemul de fișiere eșuează înainte ca OpenVPN să pornească.
Serviciul tău eșuează înainte ca OpenVPN să ruleze măcar o dată, iar eroarea vorbește despre o unitate de montare pe care nu ai configurat-o niciodată. Acesta este indiciul: systemd refuză întreaga tranzacție pentru că unitatea de montare rădăcină este mascată, iar profilul tău VPN nu a fost încă citit. Cauza obișnuită este un fișier rămas în directorul unităților de rulare, nu un fstab stricat și nu un certificat lipsă. Urmărește mai întâi fișierul, pentru că este cea mai ieftină explicație de eliminat.
Eroarea numește montarea rădăcină, nu profilul tău
systemd generează singur unitatea de montare rădăcină din informațiile de montare ale kernelului și numește unitatea -.mount pentru că o cratimă reprezintă calea rădăcină. Acea unitate există de obicei doar în memorie și nu are niciun fișier în spate. Când eroarea spune că este mascată, cineva a pus un fișier de unitate acolo unde systemd îl va încărca și a îndreptat acel fișier spre /dev/null. Masca este o stare reală, nu o greșeală de tastare în mesaj.
Unitatea de instanță eșuează pentru că graficul ei de sarcini ajunge la montarea rădăcină prin ordonare și prin propriile cerințe de montare. Tranzacția este refuzată înainte ca binarul OpenVPN să fie executat, deci nimic din configurația clientului nu poate fi cauza. De aceea schimbarea profilurilor, certificatelor sau a datelor de autentificare nu are niciun efect asupra acestei defecțiuni anume.
Verifică directorul de rulare înainte de a depana OpenVPN
Caută un fișier cu exact acest nume în directorul unităților de rulare, apoi întreabă systemd ce crede că este unitatea. Ambele răspunsuri sunt rapide și, împreună, separă un fișier rămas de o problemă reală de montare.
ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount
O mașină normală nu are un astfel de fișier, iar lista celor mascate nu conține montarea rădăcină. Dacă prima comandă afișează o legătură simbolică spre /dev/null, diagnosticul este stabilit. Același director poate conține o mască tmp.mount creată de aceleași instrumente, iar aceasta produce aceeași clasă de defecțiune sub un alt nume. Privește tot directorul, nu doar numele din eroare.
ls -la /run/systemd/system/*.mount
Dacă directorul este curat și unitatea este încă mascată, masca se află în altă parte a căii de căutare, iar systemctl cat -.mount va arăta ce fișier este încărcat.
Șterge fișierul, reîncarcă și pornește din nou
Este suficient să elimini fișierul de rulare și să reîncarci managerul, iar acest lucru nu atinge nimic care a venit dintr-un pachet. Reîncarcă înainte de pornire, pentru că systemd păstrează starea unității încărcate până când recitește directorul.
sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]
Apoi citește jurnalul serviciului însuși în loc să presupui că remedierea a funcționat. O pornire curată dovedește doar că systemd a acceptat unitatea; clientul poate muri în continuare din cauza unui profil lipsă, a unui partener inaccesibil sau a unui certificat care nu se validează. Sunt probleme obișnuite OpenVPN care erau ascunse în spatele unității mascate. Jurnalul notează ce profil a fost încărcat și dacă tunelul a fost într-adevăr stabilit. Dacă unitatea pornește și tunelul nu, ai trecut la o altă problemă, ceea ce este un progres.
journalctl -u [email protected] -b --no-pager
Deoarece /run este un sistem de fișiere temporar, o repornire șterge și fișierul. Asta face din repornire un test util: dacă serviciul funcționează după o repornire și eșuează din nou după următoarea implementare, fișierul este copt în imagine.
Împiedică revenirea lui din imagine
Un șablon de container sau de mașină virtuală care maschează unități de montare în timpul construirii va duce masca în fiecare clonă. Următorul lucru care are nevoie de sistemul de fișiere se strică, iar mesajul dă vina pe montare în loc de imaginea din care provine. Repararea în interiorul unei instanțe care rulează ascunde problema până când este creată următoarea instanță.
Caută în contextul de construire numele fișierului și comanda care îl creează, apoi scoate masca din șablon și reconstruiește. Dacă masca este cu adevărat necesară în timpul construirii, scoate-o în același strat care încheie construirea, astfel încât imaginea livrată să pornească curat. Verifică pe o clonă nouă și nu pe mașina pe care ai reparat-o manual. Este singurul test care dovedește că imaginea s-a schimbat.
Simptomul de reținut este neconcordanța dintre eroare și lucrul pe care îl configurai. Când systemd se plânge de o montare în timp ce pornești un client VPN, citește numele unității din mesaj înainte de a citi numele serviciului.