status=200/CHDIR: systemd non ha mai avviato OpenVPN

Il servizio fallisce, i log citano uno spawn e una directory, e il primo istinto è controllare la configurazione VPN. In quel file non è ancora stato letto nulla. systemd ha fallito mentre preparava il processo, prima che l'eseguibile partisse, quindi nessun parser, nessun certificato e nessun host remoto sono stati interrogati. Leggere il codice di stato come un'affermazione su systemd invece che su OpenVPN è ciò che trasforma questo in un'indagine breve.

Leggi il codice di stato prima dell'applicazione

Il codice numerico dopo il nome del servizio indica la fase che ha fallito. Un errore di directory viene segnalato come stato CHDIR, mentre un eseguibile che non è stato possibile avviare è un codice completamente diverso. I due sembrano simili in una riga di riepilogo e non hanno nulla in comune nelle loro cause.

Questa distinzione conta perché le correzioni sono in file diversi. Un errore CHDIR riguarda un percorso e come lo vede il servizio. Un errore exec riguarda il binario, il suo interprete o un mount non correlato. Cambiare il remote VPN, la lista dei cifrari o il percorso del certificato non può risolvere nessuno dei due.

Conferma che l'errore avviene all'avvio e non dopo un'esecuzione riuscita. Se il servizio funzionava ieri e ora fallisce nella stessa fase, qualcosa è cambiato nella directory, nei suoi permessi o nell'unit stessa, e quel cambiamento è la prova da cercare.

Chiedi all'unit dove vuole stare

Leggi l'unit effettiva invece del file che credi installato, perché i drop-in possono sovrascrivere la directory di lavoro senza che tu abbia mai modificato l'unit principale. L'output di show risponde direttamente alla domanda:

systemctl cat [email protected]
systemctl show [email protected] -p WorkingDirectory -p RootDirectory -p User -p ProtectHome
journalctl -u [email protected] -b --no-pager | tail -30

Per il modello del server upstream, la directory di lavoro è la directory di configurazione del server e il nome dell'istanza seleziona il profilo al suo interno. Un'istanza chiamata branch si aspetta quindi il proprio file in quella stessa directory, e un profilo collocato altrove non soddisfa affatto il requisito della directory di lavoro.

Confronta ciò che l'unit richiede con ciò che esiste. Un percorso che esisteva, un link simbolico che ora punta altrove o un nome di istanza che non corrisponde più a una directory sono tutti cambiamenti ordinari che producono esattamente questo errore.

Controlla il percorso come lo vede il servizio

La tua shell e il servizio non condividono la stessa vista del filesystem. Una directory radice o un'immagine radice configurate cambiano ciò che significa un percorso assoluto all'interno dell'unit, e un percorso ovviamente presente sull'host può mancare in quello spazio dei nomi. Leggi le impostazioni dell'unit prima di fidarti di un test manuale.

I permessi aggravano il problema. Il servizio gira come un utente specifico, e quell'utente deve poter attraversare ogni directory padre per raggiungere la destinazione, non solo leggere la destinazione stessa. Una directory leggibile da root e non attraversabile dall'utente del servizio produce un errore che sembra un percorso mancante.

namei -l /etc/openvpn/server
systemctl show [email protected] -p ProtectSystem -p ReadOnlyPaths

Anche le impostazioni di hardening fanno parte del quadro. Un'unit che nasconde le directory home o rende una parte del filesystem in sola lettura fa esattamente ciò per cui è configurata, e la directory di lavoro deve trovarsi dove il sandbox la espone ancora.

Correggi il proprietario, poi aspettati un altro errore

Correggi la disposizione o l'unit tramite chi possiede quella configurazione. Spostare un profilo nella directory attesa è una correzione legittima quando la disposizione è sbagliata, ma non spiega una directory in cui non si può entrare, quindi non trattarlo come la risposta generale.

Resisti alla scorciatoia di ampliare i permessi sull'albero di configurazione o di rimuovere il sandbox. Entrambi fanno sparire il sintomo mentre rimuovono le protezioni messe lì deliberatamente, e il prossimo guasto sarà più difficile da interpretare.

Riavvia l'istanza e leggi l'evento successivo invece di dare per scontato il successo. Il prossimo errore probabile è che OpenVPN non riesca ad aprire il suo file di configurazione, il che è un progresso: la directory di lavoro è stata raggiunta e il parser ora è in esecuzione. Segui da lì la mappatura reale dei file dell'unit invece di tornare alla risoluzione dei problemi di rete.

La guida all'esecuzione di systemd definisce come viene interpretata la directory di lavoro insieme alle directory radice e al sandboxing. Lo schema da ricordare è semplice: ogni codice di stato indica una fase diversa, e solo gli errori propri dell'applicazione descrivono l'applicazione.