Identifiera Mac-VPN-hjälparen innan du avslutar processen

Behandla ett meddelande om en hjälpare som redan körs som en ledtråd om livscykeln, inte som tillstånd att börja döda processer. Det farliga steget är inte själva stoppet utan identifieringen före det, eftersom flera komponenter med liknande namn kan finnas på en och samma Mac och bara en av dem äger anslutningen. Bygg identitetsregistret först. Bestäm sedan om ett stopp alls är rätt åtgärd.

Bygg ett identitetsregister innan du agerar

Fyra fakta gör en process identifierbar: aktuellt PID med starttid, den körbara filen och produkten den tillhör, användaren eller behörighetskontexten den körs under, och det som startade den. ps -o pid,ppid,user,etime,command -p 1234 ger dig de tre första på en rad, inklusive hur länge processen har levt. Aktivitetskontrollen visar samma information på ett vänligare sätt. Lägg till kontrollenheten, det vill säga programmet eller tjänsten som ansvarar för att starta och stoppa den. Med dessa fyra upphör en process att vara ett namn och blir ett objekt du kan resonera kring.

Om någon av de fyra är okänd, stanna där. En obekant komponent är en fråga för utgivaren eller administratören, inte ett experiment.

PID i en gammal logg tillhör någon annan nu

Process-ID:n återanvänds, och ett nummer som kopierats från gårdagens logg kan nu peka på något helt orelaterat. Jämför starttiden med tidsstämpeln i loggen innan du drar någon slutsats. Samma sak gäller ett kort namn: två byggen av en produkt kan leverera hjälpare med identiska namn och olika syften. Identitet är tupeln, aldrig bara numret.

Separera rollerna innan du rör något annat. En klients enda anslutning, en delad hjälpare som betjänar flera program och en server som tar emot andras sessioner ser alla ut som en bakgrundsprocess i en lista. Bara en av dem kan stoppas utan konsekvenser du inte har övervägt.

Stoppa genom ägaren, inte genom signalen

Börja med kontrollen som äger saken: anslutningens Koppla från-knapp, tjänstens stoppkommando som stöds, eller hanteringsagentens egen åtgärd. Dessa vägar kör den nedmontering produkten förväntar sig, vilket inkluderar att ta bort rutter och stänga tunnelenheten. En signal hoppar över allt detta och lämnar kvar tillstånd.

Titta på vad som finns kvar efteråt. En process som ligger kvar kan vänta på nästa anslutning, vilket är ett designval och inte ett misslyckat stopp.

Varför en övervakare startar om det du dödade

Om en startdaemon eller en automatisk anslutningspolicy vill att tunneln ska vara uppe uttrycker det ingenting att döda processen. Övervakaren ser avslutet och startar den igen, ibland innan du hunnit läsa klart loggen.

Hitta övervakaren innan du slåss mot den. launchctl list visar inlästa jobb och deras etiketter, och ett jobb med keep-alive-inställning startar om vid avslut, precis som det är designat. Rätt åtgärd där är att ändra avsikten: ladda ur jobbet, stäng av den automatiska anslutningspolicyn eller be administratören göra det. Tvingad avslutning är ett annat verktyg med en annan betydelse, och det hör till en dokumenterad återställningsprocedur för en fastnad process, inte till rutinmässig anslutningshantering.

Registrera livscykelhändelsen, inte dödandet

Skriv ned komponentens identitet, klientversionen, den första relevanta livscykelhändelsen och vad du gjorde. Händelsen är viktigare än åtgärden, eftersom två instanser som dyker upp vid inloggning är ett startordningsproblem som kommer att återkomma. En registrering som namnger den körbara filen och dess kontrollenhet gör att nästa person kan återskapa det.

Verifiera sedan det avsedda tillståndet: tjänsten användaren behövde och den privata resurs den når. Undvik pipelinen som söker efter en delsträng och tvångsdödar varje träff, eftersom den kastar bort allt ovanstående och vanligtvis förstör beviset för varför två instanser fanns. Om processen fortsätter att komma tillbaka är fyndet ett konfigurations- eller ordningsfel, och rättelsen hör till den som äger klientens startbeteende.