Identifizieren Sie einen VPN-Helper auf dem Mac, bevor Sie den Prozess beenden

Behandeln Sie eine Meldung über einen bereits laufenden Helper als Hinweis auf den Lebenszyklus, nicht als Erlaubnis, Prozesse zu töten. Der gefährliche Schritt ist nicht das Stoppen selbst, sondern die Identifikation davor, denn auf einem Mac können mehrere Komponenten mit ähnlichen Namen existieren, und nur eine davon besitzt die Verbindung. Erstellen Sie zuerst den Identitätsdatensatz. Entscheiden Sie dann, ob ein Stopp überhaupt die richtige Handlung ist.

Erstellen Sie einen Identitätsdatensatz, bevor Sie handeln

Vier Fakten machen einen Prozess identifizierbar: die aktuelle PID mit ihrer Startzeit, die ausführbare Datei und das Produkt, zu dem sie gehört, der Benutzer- oder Privilegienkontext, unter dem er läuft, und was auch immer ihn gestartet hat. ps -o pid,ppid,user,etime,command -p 1234 liefert Ihnen die ersten drei in einer Zeile, einschließlich der Zeit, die der Prozess bereits lebt. Aktivitätsanzeige zeigt dieselben Informationen mit freundlicherer Oberfläche. Fügen Sie den Controller hinzu, also die Anwendung oder den Dienst, der für Start und Stopp verantwortlich ist. Mit diesen vier hört ein Prozess auf, ein Name zu sein, und wird zu einem Objekt, über das Sie nachdenken können.

Wenn einer der vier unbekannt ist, halten Sie dort an. Eine unbekannte Komponente ist eine Frage an den Herausgeber oder den Administrator, kein Experiment.

Die PID in einem alten Protokoll gehört jetzt jemand anderem

Prozess-IDs werden wiederverwendet, und eine aus dem gestrigen Protokoll kopierte Nummer kann jetzt auf etwas völlig Unzusammenhängendes zeigen. Vergleichen Sie die Startzeit mit dem Zeitstempel des Protokolls, bevor Sie eine Schlussfolgerung ziehen. Dasselbe gilt für einen kurzen Namen: Zwei Builds eines Produkts können Helper mit identischen Namen und unterschiedlichen Zwecken ausliefern. Identität ist das Tupel, niemals die Nummer allein.

Trennen Sie die Rollen, bevor Sie etwas anderes anfassen. Der Client einer einzelnen Verbindung, ein gemeinsamer Helper, der mehrere Anwendungen bedient, und ein Server, der Sitzungen anderer Leute annimmt, sehen in einer Liste alle wie ein Hintergrundprozess aus. Nur einer von ihnen kann gestoppt werden, ohne Konsequenzen, die Sie nicht bedacht haben.

Stoppen Sie über den Eigentümer, nicht über das Signal

Beginnen Sie mit dem Steuerelement, das die Sache besitzt: der Trennen-Schaltfläche der Verbindung, dem unterstützten Stoppbefehl des Dienstes oder der eigenen Aktion des Verwaltungsagenten. Diese Wege führen den Abbau aus, den das Produkt erwartet, einschließlich des Entfernens von Routen und des Schließens des Tunnelgeräts. Ein Signal überspringt all das und hinterlässt Zustand.

Beobachten Sie, was danach übrig bleibt. Ein Prozess, der im Speicher bleibt, wartet möglicherweise auf die nächste Verbindung, was eine Designentscheidung und kein fehlgeschlagener Stopp ist.

Warum ein Supervisor neu startet, was Sie getötet haben

Wenn ein Launch-Daemon oder eine Auto-Verbindungsrichtlinie den Tunnel aktiv halten soll, drückt das Töten des Prozesses nichts aus. Der Supervisor sieht den Exit und startet ihn erneut, manchmal bevor Sie das Protokoll zu Ende gelesen haben.

Finden Sie den Supervisor, bevor Sie gegen ihn kämpfen. launchctl list zeigt geladene Jobs und ihre Labels, und ein Job mit einer Keep-Alive-Einstellung startet beim Exit konstruktionsbedingt neu. Die richtige Handlung dort ist, die Absicht zu ändern: den Job entladen, die Auto-Verbindungsrichtlinie deaktivieren oder den Administrator darum bitten. Erzwungenes Beenden ist ein anderes Werkzeug mit einer anderen Bedeutung und gehört zu einem dokumentierten Wiederherstellungsverfahren für einen festgefahrenen Prozess, nicht zur routinemäßigen Verbindungsverwaltung.

Halten Sie das Lebenszyklusereignis fest, nicht das Töten

Notieren Sie die Identität der Komponente, die Client-Version, das erste relevante Lebenszyklusereignis und was Sie getan haben. Das Ereignis ist wichtiger als die Handlung, denn zwei Instanzen, die beim Anmelden erscheinen, sind ein Startreihenfolgeproblem, das sich wiederholen wird. Ein Datensatz, der die ausführbare Datei und ihren Controller nennt, erlaubt der nächsten Person, es zu reproduzieren.

Prüfen Sie dann den beabsichtigten Zustand: den Dienst, den der Benutzer brauchte, und die private Ressource, die er erreicht. Vermeiden Sie die Pipeline, die nach einem Teilstring grept und jede Übereinstimmung zwangsweise beendet, denn sie verwirft all das oben Genannte und zerstört meist den Beweis dafür, warum zwei Instanzen existierten. Wenn der Prozess immer wieder zurückkommt, ist der Befund ein Konfigurations- oder Reihenfolgefehler, und die Korrektur gehört zu dem, der das Startverhalten des Clients verantwortet.