Identificer en VPN-helper på Mac, før du dræber processen
Match en VPN-proces med dens eksekverbare fil, dens controller og dens netværksrolle, før du stopper den, og brug derefter ejerens stopvej i stedet for et signal.
Behandl en besked om en helper, der allerede kører, som et livscyklusspor, ikke som tilladelse til at begynde at dræbe processer. Det farlige skridt er ikke selve standsningen, men identifikationen før den, fordi flere komponenter med lignende navne kan findes på én Mac, og kun én af dem ejer forbindelsen. Byg identitetsregistret først. Beslut derefter, om en standsning overhovedet er den rigtige handling.
Byg et identitetsregister, før du handler
Fire fakta gør en proces identificerbar: det aktuelle PID med dets starttid, den eksekverbare fil og det produkt, den tilhører, den bruger- eller privilegiekontekst, den kører under, og hvad der end startede den. ps -o pid,ppid,user,etime,command -p 1234 giver dig de første tre på én linje, inklusive hvor længe processen har været i live. Activity Monitor viser de samme oplysninger med et venligere ansigt. Tilføj controlleren, altså det program eller den tjeneste, der er ansvarlig for at starte og stoppe den. Med de fire holder en proces op med at være et navn og bliver et objekt, du kan ræsonnere om.
Hvis en af de fire er ukendt, så stop der. En ukendt komponent er et spørgsmål til udgiveren eller administratoren, ikke et eksperiment.
PID'et i en gammel log tilhører nu en anden
Proces-ID'er genbruges, og et tal kopieret fra gårsdagens log kan nu pege på noget helt urelateret. Sammenlign starttiden med loggens tidsstempel, før du drager nogen konklusion. Det samme gælder et kort navn: to builds af ét produkt kan levere helpers med identiske navne og forskellige formål. Identitet er tuplen, aldrig tallet alene.
Adskil rollerne, før du rører noget andet. En enkelt forbindelses klient, en delt helper, der betjener flere programmer, og en server, der accepterer andres sessioner, ser alle ud som en baggrundsproces på en liste. Kun én af dem kan stoppes uden konsekvenser, du ikke har overvejet.
Stop gennem ejeren, ikke gennem signalet
Start med den kontrol, der ejer tingen: forbindelsens Afbryd-knap, tjenestens understøttede stopkommando eller administrationsagentens egen handling. De veje kører den nedtagning, produktet forventer, hvilket omfatter fjernelse af ruter og lukning af tunnel-enheden. Et signal springer det hele over og efterlader tilstand.
Se, hvad der er tilbage bagefter. En proces, der forbliver i hukommelsen, venter måske på den næste forbindelse, hvilket er et designvalg snarere end en mislykket standsning.
Hvorfor en supervisor genstarter det, du dræbte
Hvis en launch-daemon eller en politik for automatisk forbindelse ønsker, at tunnelen skal være oppe, udtrykker det intet at dræbe processen. Supervisoren ser afslutningen og starter den igen, nogle gange før du er færdig med at læse loggen.
Find supervisoren, før du kæmper mod den. launchctl list viser indlæste jobs og deres etiketter, og et job med en keep-alive-indstilling genstarter ved afslutning efter design. Den korrekte handling der er at ændre hensigten: aflæs jobbet, deaktiver politikken for automatisk forbindelse, eller bed administratoren om det. Tvangslukning er et andet værktøj med en anden betydning, og det hører til en dokumenteret gendannelsesprocedure for en fastlåst proces snarere end til rutinemæssig forbindelsesstyring.
Registrer livscyklushændelsen, ikke drabet
Skriv komponentens identitet ned, klientversionen, den første relevante livscyklushændelse og hvad du gjorde. Hændelsen betyder mere end handlingen, fordi to instanser, der vises ved login, er et opstartsrækkefølgeproblem, der vil gentage sig. En registrering, der navngiver den eksekverbare fil og dens controller, lader den næste person reproducere det.
Verificer derefter den tilsigtede tilstand: den tjeneste, brugeren havde brug for, og den private ressource, den når. Undgå den pipeline, der grep'er en understreng og tvangsdræber hvert match, da den kasserer alt ovenstående og normalt ødelægger beviset for, hvorfor to instanser eksisterede. Hvis processen bliver ved med at komme tilbage, er fundet en konfigurations- eller rækkefølgefejl, og rettelsen hører til den, der ejer klientens opstartsadfærd.