Identifica un helper VPN sul Mac prima di uccidere il processo

Tratta un messaggio su un helper già in esecuzione come un indizio sul ciclo di vita, non come il permesso di iniziare a uccidere processi. Il passo pericoloso non è l'arresto in sé ma l'identificazione che lo precede, perché su un Mac possono esistere diversi componenti con nomi simili e solo uno di essi possiede la connessione. Costruisci prima la scheda di identità. Poi decidi se un arresto sia davvero l'azione giusta.

Costruisci una scheda di identità prima di agire

Quattro fatti rendono un processo identificabile: il PID corrente con la sua ora di avvio, l'eseguibile e il prodotto a cui appartiene, il contesto utente o di privilegi in cui viene eseguito, e qualunque cosa lo abbia avviato. ps -o pid,ppid,user,etime,command -p 1234 ti dà i primi tre su una riga, compreso da quanto tempo il processo è vivo. Activity Monitor mostra le stesse informazioni con un volto più amichevole. Aggiungi il controllore, cioè l'applicazione o il servizio responsabile di avviarlo e fermarlo. Con questi quattro, un processo smette di essere un nome e diventa un oggetto su cui puoi ragionare.

Se uno dei quattro è sconosciuto, fermati lì. Un componente sconosciuto è una domanda per l'editore o per l'amministratore, non un esperimento.

Il PID in un vecchio registro ora appartiene a qualcun altro

Gli ID di processo vengono riciclati, e un numero copiato dal registro di ieri può ora puntare a qualcosa di completamente estraneo. Confronta l'ora di avvio con il timestamp del registro prima di trarre qualsiasi conclusione. Lo stesso vale per un nome corto: due build di uno stesso prodotto possono fornire helper con nomi identici e scopi diversi. L'identità è la tupla, mai solo il numero.

Separa i ruoli prima di toccare qualsiasi altra cosa. Il client di una singola connessione, un helper condiviso che serve più applicazioni e un server che accetta sessioni altrui sembrano tutti un processo in background in un elenco. Solo uno di essi può essere fermato senza conseguenze che non hai considerato.

Ferma tramite il proprietario, non tramite il segnale

Parti dal controllo che possiede la cosa: il pulsante Disconnetti della connessione, il comando di arresto supportato dal servizio o l'azione propria dell'agente di gestione. Quei percorsi eseguono lo smontaggio che il prodotto si aspetta, che comprende la rimozione delle rotte e la chiusura del dispositivo del tunnel. Un segnale salta tutto questo e lascia stato dietro di sé.

Osserva cosa rimane dopo. Un processo che resta residente potrebbe aspettare la connessione successiva, che è una scelta di progettazione e non un arresto fallito.

Perché un supervisore riavvia ciò che hai ucciso

Se un demone di avvio o una politica di connessione automatica vuole che il tunnel sia attivo, uccidere il processo non esprime nulla. Il supervisore vede l'uscita e lo riavvia, a volte prima che tu abbia finito di leggere il registro.

Trova il supervisore prima di combatterlo. launchctl list mostra i job caricati e le loro etichette, e un job con un'impostazione di mantenimento in vita si riavvia all'uscita per progetto. L'azione corretta lì è cambiare l'intento: scarica il job, disattiva la politica di connessione automatica o chiedi all'amministratore di farlo. La chiusura forzata è un altro strumento con un altro significato, e appartiene a una procedura di ripristino documentata per un processo bloccato, non alla gestione ordinaria delle connessioni.

Registra l'evento del ciclo di vita, non l'uccisione

Annota l'identità del componente, la versione del client, il primo evento rilevante del ciclo di vita e ciò che hai fatto. L'evento conta più dell'azione, perché due istanze che compaiono all'accesso sono un problema di ordine di avvio che si ripeterà. Una scheda che nomina l'eseguibile e il suo controllore permette alla persona successiva di riprodurlo.

Poi verifica lo stato previsto: il servizio di cui l'utente aveva bisogno e la risorsa privata che raggiunge. Evita la pipeline che cerca una sottostringa e uccide a forza ogni corrispondenza, perché scarta tutto quanto sopra e di solito distrugge la prova del perché esistevano due istanze. Se il processo continua a tornare, il riscontro è un difetto di configurazione o di ordine, e la correzione spetta a chi possiede il comportamento di avvio del client.