File PID presente, nessun tunnel: OpenVPN ha mai funzionato?

Quando il launcher rifiuta di avviare OpenVPN perché esiste già un file PID, la lettura naturale è che un tunnel sia attivo da qualche parte. Quella lettura è sbagliata abbastanza spesso da meritare un controllo prima di cancellare qualsiasi cosa. Un file in una directory di runtime è contabilità, e la contabilità sopravvive a crash, riavvii e arresti interrotti che non hanno lasciato alcun processo. Due domande decidono il caso: esiste un processo vivo, e quel processo appartiene a questa istanza.

Iniziate dal servizio, non dal file

Il rifiuto di solito viene da un launcher e non da OpenVPN stesso. Legge un percorso, vi trova qualcosa e si ferma prima di analizzare una configurazione. La prima domanda riguarda quindi il contratto del launcher, non il tunnel.

Leggete l'unità o lo script che ha stampato il messaggio e notate tre cose: il percorso che controlla, il tipo di servizio che dichiara e se è responsabile della scrittura del file. Un'unità moderna può usare una supervisione semplice o notify e non toccare mai un file PID, mentre un vecchio script init può crearne uno da solo. Copiare un controllo da un modello all'altro produce esattamente questo tipo di rifiuto. Scoprite quale modello è in uso prima di interpretare qualsiasi cosa.

Solo allora la domanda diventa se un'istanza sia davvero in esecuzione.

Verificate se quell'identificatore appartiene alla vostra istanza

Un numero in un file prova che è stato scritto un numero. Non prova che esista ora un processo con quell'identificatore, e certamente non prova che il processo sia vostro, perché gli identificatori vengono riutilizzati dopo un riavvio.

Confrontate l'ora di avvio del processo con il timestamp del file, l'eseguibile con il comando dell'unità e l'appartenenza al servizio con il nome dell'unità. Una discrepanza in uno dei tre significa che state guardando la contabilità, non un tunnel.

Su un host che esegue container o più spazi dei nomi, un identificatore può avere senso in una vista e mancare in un'altra. Non vedere un processo non è nemmeno prova che non esista, se il vostro account non può ispezionarlo. Controllate dal contesto che il launcher usa prima di trarre conclusioni.

systemctl status [email protected]
ps -o pid,lstart,args -p "$(cat /run/openvpn/vpn.pid)"

Cosa ha promesso il launcher di fare con il file

PIDFile= dice al gestore dei servizi da dove leggere l'identificatore del processo principale. Il gestore non scrive quel file, ma rimuove quello sopravvissuto dopo l'arresto, ed è esattamente per questo che un'uscita interrotta può lasciare un file.

Questa divisione di responsabilità spiega due sintomi che le persone segnalano come bug. Un file che non compare mai significa che il demone o il suo script non sono riusciti a scriverlo, non che la supervisione sia configurata male. Un file che sopravvive a un arresto significa che il percorso di arresto non è mai stato completato.

Spiega anche perché le linee guida attuali suggeriscano di evitare la convenzione quando la supervisione può seguire direttamente il processo principale. Quelle linee guida non sono un permesso per cambiare il tipo di un'unità pacchettizzata, perché il comportamento del demone in primo piano, in biforcazione o in notifica deve corrispondere a ciò che l'unità dichiara. Cambiate il tipo senza cambiare il demone e ottenete un'unità che segnala un errore mentre il tunnel è attivo, o il contrario. Abbinate la coppia, o lasciate entrambe. Il riferimento del servizio systemd descrive questa ripartizione di proprietà.

Arresto pulito contro uscita interrotta

Un arresto pulito chiede al demone di uscire, lo attende e lascia che il gestore riordini la propria contabilità. Un'uscita interrotta, un processo ucciso o un riavvio a metà arresto saltano parti di quella sequenza, e il file è ciò che resta. Trovarlo dopo un crash vi dice che l'arresto non è terminato, non che qualcosa sia in ascolto.

Confrontate il timestamp del file con l'ultimo avvio e con l'ultimo arresto dell'unità.

Poi verificate le prove vive direttamente. Un socket legato alla porta VPN e un'interfaccia tunnel con un indirizzo sono la prova che qualcosa è in esecuzione, in un modo in cui un file di testo in una directory di runtime non lo è mai. Se mancano entrambi, non è in esecuzione nulla, qualunque cosa affermi il file.

Smettete di eliminare il file per abitudine

Eliminarlo è un passo di ripristino legittimo una volta stabilito che nessuna istanza lo possiede e che il launcher documenta questo comportamento.

Come abitudine permanente prima dell'avvio, annulla il controllo che state aggirando. Se i file obsoleti tornano dopo ogni arresto pulito, lo scrittore e il ciclo di vita dell'arresto non concordano su chi possiede il percorso, e quella discordanza è il bug che vale la pena correggere.

Mantenete una via indipendente verso l'host, avviate un'istanza tramite il suo gestore normale e leggete il primo risultato. La persona successiva riceve un'unità che o funziona o si spiega.