OpenVPN avviato ma non ha stampato nulla: controllate prima log-append

Avviate OpenVPN da una shell con un file di configurazione, e il terminale resta lì senza alcun output. Nessun banner, nessun errore, nessun prompt. L'istinto dice che l'avvio è fallito, quindi avviate un'altra copia, poi un'altra, e la macchina finisce con diverse istanze mezze configurate. Prima di tutto ciò, controllate nel profilo una direttiva che ha già reindirizzato il registro altrove. Il silenzio è una proprietà della console, non del processo.

Il silenzio ha due spiegazioni molto diverse

La prima è che il processo funziona bene e scrive in un file che non state osservando. La seconda è che è uscito subito con un errore registrato in quello stesso file.

Entrambe lasciano un terminale vuoto, e una sola domanda le separa: c'è un processo adesso, e cosa c'è nel file in cui gli è stato detto di scrivere. Rispondete prima di toccare di nuovo la configurazione. Riavviare per ottenere output è il modo in cui due istanze finiscono per contendersi un unico dispositivo tunnel e la stessa porta, il che produce errori che non hanno nulla a che fare con il problema originale.

Trovate la direttiva, poi trovate il processo.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

Trovate la destinazione usata dal processo in esecuzione

Leggete il profilo con cui il processo è stato realmente avviato, non quello che avete modificato. Un'istanza gestita da un servizio di solito carica un percorso diverso e gira con una directory di lavoro diversa, quindi un nome di file relativo si risolve in un punto che non vi aspettavate.

Una direttiva cd esplicita rende quella distinzione più netta, perché il percorso relativo si sposta con il cambio di directory. Se avete ereditato questa configurazione, il file può trovarsi in un posto dove ora nessuno lo cercherebbe.

Confrontate l'ora di modifica del file con il momento in cui l'avete avviato. Un registro della settimana scorsa è una prova sulla settimana scorsa. Poi leggete le ultime righe del file che è cambiato, e trattate ciò che c'è come il messaggio di avvio che vi mancava.

log contro log-append: prova e cancellazione

log-append aggiunge a ciò che è già nel file. log apre il file in scrittura e lo tronca, quindi passare dall'uno all'altro può cancellare l'esecuzione che stavate per leggere.

Se qualcuno ha cambiato la direttiva durante il debug, la prova precedente è già sparita e la dimensione del file sembrerà sospettosamente piccola. Vale la pena saperlo prima di confrontare due esecuzioni e concludere che qualcosa è cambiato. Cancellate un registro di proposito o conservatelo, ma sappiate quale delle due cose avete fatto. Una prova che avete rimosso deliberatamente è più facile da motivare di una prova persa per caso.

Nessuna delle due opzioni crea le directory padre mancanti, e nessuna concede accesso tramite i permessi del file system o una sandbox di servizio. Un percorso che nella configurazione sembra corretto può comunque non essere scrivibile dall'account con cui gira il demone, e in quel caso il demone può fallire prima di poter segnalare qualcosa. Controllate che la directory esista e chi ne sia proprietario prima di supporre che il problema sia il nome del file.

Quando un wrapper di servizio cattura l'output

Sotto systemd, l'output standard e l'errore vanno nel journal a meno che una direttiva di file esplicita non abbia la precedenza, e un wrapper del fornitore può catturarli in un posto completamente diverso.

Ecco perché lo stesso profilo si comporta diversamente da una shell e da un'unità. L'ambiente dell'unità, la sua directory di lavoro e i suoi flussi standard differiscono tutti dalla vostra shell interattiva. Un percorso relativo può risolversi in un contesto e non arrivare da nessuna parte nell'altro. Leggete la definizione dell'unità quando i due sono in disaccordo, non il profilo.

Confrontate le due modalità di avvio invece di concludere che una delle due è rotta. Leggete la riga di comando dell'unità e il suo ambiente, poi leggete il journal per la stessa finestra temporale. Se il wrapper reindirizza l'output al proprio file, quel file è ora il vostro registro, e le direttive OpenVPN sono irrilevanti rispetto a dove sono andati i messaggi.

Alzate la verbosità solo dopo che riuscite a leggerla

Aumentare la verbosità prima di aver trovato la destinazione produce solo più testo in un punto che non state guardando.

Una volta che sapete dove finisce l'output, un livello moderato mostra che il profilo viene analizzato e che si tenta la connessione. Due o tre bastano per un problema di avvio. I livelli più alti si guadagnano il posto quando il guasto è un dettaglio della negoziazione, e fanno anche crescere rapidamente il file.

Poi leggete l'errore reale. Un terminale silenzioso non prova nulla sulla salita del tunnel, e il guasto registrato nel file è quello che vale la pena correggere.