Arrestare i servizi VPN e proxy di Linux nell'ordine giusto

Gli arresti che si bloccano mentre gira un proxy sono raramente un difetto della VPN, anche quando la VPN è l'ultima cosa visibile sullo schermo. Le applicazioni dietro il proxy aspettano ancora un percorso che sta per sparire, e all'unità che possiede il tunnel non è ancora stato chiesto di chiuderlo. Quello che sembra un servizio lento è di solito un problema di ordine. L'ordine risolve più di questi casi di qualsiasi modifica del timeout.

Lavorate verso l'esterno in ordine inverso: prima i consumatori, poi il proxy, poi il tunnel, ciascuno fermato dal componente che lo ha avviato.

Elencate le unità prima di fermare qualsiasi cosa

Annotate l'unità dell'applicazione, l'unità del proxy e il proprietario della VPN coinvolti in un'esecuzione normale. Aggiungete ogni resolver o helper con il proprio smontaggio, perché sono quelli che la gente dimentica alle due di notte. Senza quell'elenco, il primo comando di arresto che digitate sceglie una vittima a caso.

I nomi sono una prova debole. Un proxy utente, un proxy di sistema e il tunnel di un altro account possono condividere il nome pur avendo cicli di vita del tutto scollegati.

Completate il lavoro, poi fermate il consumatore

Un arresto pianificato inizia dall'applicazione: lasciatela completare o annullare le sue richieste, poi fermate il proxy tramite la sua unità di servizio. Se l'applicazione deve continuare a funzionare dopo che il tunnel sparisce, organizzatelelo deliberatamente invece di lasciarla agganciata a una rotta che sta per svanire.

Le richieste in corso durante l'arresto devono finire nel registro, perché è da lì che viene la tempesta di nuovi tentativi al prossimo avvio.

ExecStop ed ExecStopPost sono strumenti diversi

ExecStop= è l'operazione di arresto sincrona; ExecStopPost= è la pulizia che viene eseguita anche dopo un avvio fallito. Un comando di arresto che si limita a inviare un segnale a un processo e ritorna lascia che systemd prosegua mentre il consumatore sta ancora svuotando. Tutto ciò che deve accadere comunque appartiene alla variante successiva, e tutto ciò che deve bloccare l'arresto appartiene a quella sincrona. Ispezionate l'unità effettiva e i suoi drop-in invece di modificare un file del pacchetto sul posto.

Un grafo delle dipendenze ordina i lavori di arresto. Non trasforma uno script asincrono in sincrono, né costringe un'applicazione remota a salvare i suoi dati.

Limitate l'arresto e sappiate quanto costa il limite

TimeoutStopSec= limita sia il comando di arresto sia la terminazione propria del servizio, e systemd passa a un arresto forzato quando il limite scade. Scegliete il valore dal comportamento reale di svuotamento dell'applicazione, e annotate cosa può andare perso quando scatta. Un numero scelto perché la macchina deve spegnersi più in fretta è un'impostazione di perdita di dati mascherata.

Quando un arresto è ancora lento, catturate l'unità, i suoi processi figli, l'intervallo del journal e il risultato del timeout. Accorciare ogni timeout o ricorrere a un arresto indiscriminato è il modo in cui gli arresti puliti diventano stato corrotto al prossimo avvio.

Disconnettete tramite il proprietario, poi provate tre casi

Una volta fermi i consumatori, chiedete al gestore che possiede il tunnel di disconnettersi: l'istanza systemd, la connessione attiva di NetworkManager o il servizio del fornitore. Uccidere un processo OpenVPN non correlato non rimuove necessariamente la sessione che ha fornito la rotta, e un proxy con politica di riavvio può ricreare una richiesta mentre smontate il percorso. Coordinate quella politica con l'arresto pianificato prima di iniziare.

Provate un arresto normale, un arresto con una richiesta attiva e un arresto in cui il tunnel fallisce per primo. Una sequenza ripetibile con una scadenza batte uno spegnimento rapido che funziona una volta.