L’unità -.mount è mascherata: il client OpenVPN non si avvia

Il tuo servizio fallisce prima che OpenVPN venga mai eseguito, e l’errore parla di un’unità di mount che non hai mai configurato. Questo è l’indizio: systemd rifiuta l’intera transazione perché l’unità di mount radice è mascherata, e il tuo profilo VPN non è ancora stato letto. La causa abituale è un file rimasto nella directory delle unità di runtime, non un fstab rotto e non un certificato mancante. Segui prima il file, perché è la spiegazione più economica da escludere.

L’errore nomina il mount radice, non il tuo profilo

systemd genera da sé l’unità di mount radice dalle informazioni di mount del kernel, e chiama l’unità -.mount perché un trattino rappresenta il percorso radice. Quell’unità di solito esiste solo in memoria e non ha alcun file dietro. Quando l’errore dice che è mascherata, qualcuno ha messo un file di unità dove systemd lo caricherà e ha puntato quel file a /dev/null. La maschera è uno stato reale, non un refuso nel messaggio.

L’unità di istanza fallisce perché il suo grafo dei job raggiunge il mount radice tramite l’ordinamento e tramite i propri requisiti di mount. La transazione viene rifiutata prima che il binario di OpenVPN venga eseguito, quindi nulla nella configurazione del client può essere la causa. Per questo cambiare profili, certificati o credenziali non ha alcun effetto su questo guasto specifico.

Controlla la directory di runtime prima di fare debug di OpenVPN

Cerca un file con esattamente quel nome nella directory delle unità di runtime, poi chiedi a systemd che cosa pensa che sia l’unità. Entrambe le risposte sono rapide e, insieme, distinguono un file rimasto da un vero problema di mount.

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

Una macchina normale non ha quel file, e l’elenco delle unità mascherate non contiene il mount radice. Se il primo comando stampa un collegamento simbolico a /dev/null, la diagnosi è chiusa. La stessa directory può contenere una maschera tmp.mount creata dagli stessi strumenti, e questo produce la stessa classe di guasto sotto un altro nome. Guarda l’intera directory e non solo il nome citato nell’errore.

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

Se la directory è pulita e l’unità resta mascherata, la maschera vive altrove nel percorso di ricerca, e systemctl cat -.mount mostrerà quale file viene caricato.

Elimina il file, ricarica e riavvia

Rimuovere il file di runtime e ricaricare il gestore basta, e non tocca nulla che provenga da un pacchetto. Ricarica prima di avviare, perché systemd conserva lo stato dell’unità caricata finché non rilegge la directory.

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

Poi leggi il journal del servizio stesso invece di dare per scontato che la correzione abbia funzionato. Un avvio pulito prova solo che systemd ha accettato l’unità; il client può ancora morire su un profilo mancante, un peer irraggiungibile o un certificato che non si convalida. Sono problemi OpenVPN ordinari che erano nascosti dietro l’unità mascherata. Il journal registra quale profilo è stato caricato e se il tunnel si è davvero stabilito. Se l’unità parte e il tunnel no, sei passato a un altro problema, il che è un progresso.

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

Poiché /run è un file system temporaneo, un riavvio cancella anche il file. Questo rende il riavvio un test utile: se il servizio funziona dopo un riavvio e fallisce di nuovo dopo la distribuzione successiva, il file viene incorporato nell’immagine.

Impedisci che torni dall’immagine

Un modello di container o di macchina virtuale che maschera unità di mount durante la sua build porterà quella maschera in ogni clone. La prossima cosa che ha bisogno del file system si rompe, e il messaggio incolpa il mount invece dell’immagine da cui proviene. Correggerlo dentro un’istanza in esecuzione nasconde il problema fino alla creazione dell’istanza successiva.

Cerca nel contesto di build il nome del file e il comando che lo crea, poi rimuovi la maschera dal modello e ricostruisci. Se la maschera serve davvero durante la build, rimuovila nello stesso livello che conclude la build, così l’immagine spedita parte pulita. Verifica su un clone nuovo e non sulla macchina che hai riparato a mano. È l’unico test che dimostra che l’immagine è cambiata.

Il sintomo da ricordare è la discrepanza tra l’errore e ciò che stavi configurando. Quando systemd si lamenta di un mount mentre avvii un client VPN, leggi il nome dell’unità nel messaggio prima di leggere il nome del servizio.