Qualcosa avvia continuamente un'unità OpenVPN: trova l'origine

Un'istanza OpenVPN compare all'avvio con un nome che non riconosci, e fermarla funziona fino al riavvio successivo. Questo schema significa che hai rimosso il processo ma non l'attivazione. Sono due oggetti diversi, e solo uno dei due è visibile in una schermata di stato. Trovare l'attivazione richiede quattro comandi di sola lettura e una decisione.

Nomina prima l'unità esatta

Parti dal nome dell'unità nel journal, non dal nome di un file di profilo. L'istanza può chiamarsi openvpn@, openvpn-client@, openvpn-server@ o qualcosa di specifico della distribuzione, e indovinare il nome ti porta al modello sbagliato. L'output di stato nomina l'unità che è stata realmente eseguita, ed è l'unico nome che conta qui. Copialo esattamente, incluso qualsiasi suffisso.

I comandi seguenti descrivono quell'unità senza cambiare nulla. systemctl show riporta il percorso del frammento, il percorso di origine, lo stato del file dell'unità, eventuali drop-in e cosa l'ha attivata. list-dependencies --reverse mostra quali unità caricate vi puntano. Entrambi sono di sola lettura, quindi eseguili prima di formulare una teoria.

Sostituisci il nome osservato ovunque. Un nome di esempio copiato è il modo più comune di indagare il servizio sbagliato, e produce risposte sicure su un'unità che non è mai stata eseguita.

Leggi il modello per conoscere il nome del file

Un'unità di istanza è un'espansione di un modello, e il modello decide quale file di configurazione legge. Una riga di comando che termina in un segnaposto per istanza viene risolta nel nome dell'istanza più il suffisso. Se il suffisso è .conf e l'istanza si chiama old, il file è old.conf. Se chiami l'istanza old.conf, lo stesso modello chiede old.conf.conf.

Quel dettaglio spiega una classe di duplicati. Qualcuno aggiunge una seconda istanza con il nome sbagliato, la prima continua a funzionare, e l'host finisce con due tunnel e un registro confuso.

Leggi il modello effettivo invece del file che ricordi di aver modificato. Un drop-in può sostituire la riga di comando, e la sostituzione è ciò che viene eseguito all'avvio.

Traccia come entra nella transazione di avvio

Tre percorsi sono comuni: un collegamento wants da un target, un requisito di un'altra unità o un'unità generata da un generatore di pacchetti. L'elenco delle dipendenze inverse copre i primi due come voci caricate del grafo. Non copre un timer, un hook o una richiesta esterna, ed è per questo che l'elenco è una prova e non un audit completo.

L'output generato in /run/systemd/generator è un prodotto, non una fonte. Modificarlo sopravvive solo fino alla generazione successiva, ed è per questo che una correzione applicata lì sembra riuscita e poi torna indietro.

Controlla l'input documentato del pacchetto prima di supporre da dove legge il generatore. Una scansione non documentata di una directory è la ragione abituale per cui un'unità compare senza un collegamento di attivazione.

Rimuovi l'attivazione, non solo il processo

Se l'istanza è attivata direttamente e davvero obsoleta, systemctl disable --now la ferma e rimuove il collegamento di avvio in un solo passo. Verifica prima che questo tunnel non sia il tuo unico percorso amministrativo verso l'host. Il comando è un esempio di ciclo di vita, non un invito a fermare ogni VPN della macchina. Esegui la verifica prima del comando, non dopo.

Le due metà sono separabili e spesso confuse. Disattivare non ferma un servizio in esecuzione, e fermare non rimuove l'attivazione, quindi un comando parziale spiega un problema che ritorna all'avvio.

Un'unità disattivata può comunque essere avviata da un'altra unità o da una richiesta esplicita. Quando un generatore possiede l'attivazione, correggi il suo input invece di disattivarne l'output. Il mascheramento blocca più percorsi ma può rompere le dipendenze, quindi non sostituisce la comprensione.

Verifica con un riavvio, non con una schermata di stato

Ricarica systemd se le definizioni delle unità o gli input del generatore sono cambiati, poi ispeziona lo stato risultante. Una ricarica del demone non spinge un nuovo profilo in un tunnel in esecuzione, quindi i due controlli sono separati. Pianifica un riavvio e conferma che l'istanza resti assente mentre il tunnel previsto funziona ancora.

Conserva il vecchio profilo finché la sua proprietà non è chiara, poi ritiralo tramite il processo previsto. Il successo è un'unità assente e un percorso di accesso funzionante, non un'unità guasta che manca in una schermata.