Identifiser Mac-VPN-hjelperen før du avslutter prosessen

Behandle en melding om en hjelper som allerede kjører som et livssyklusspor, ikke som tillatelse til å begynne å drepe prosesser. Det farlige trinnet er ikke selve stoppet, men identifiseringen foran det, fordi flere komponenter med like navn kan finnes på samme Mac, og bare én av dem eier tilkoblingen. Bygg identitetsregisteret først. Deretter avgjør du om et stopp i det hele tatt er riktig handling.

Bygg et identitetsregister før du handler

Fire fakta gjør en prosess identifiserbar: gjeldende PID med starttid, kjørbar fil og produktet den hører til, brukeren eller privilegiekonteksten den kjører under, og det som startet den. ps -o pid,ppid,user,etime,command -p 1234 gir deg de tre første på én linje, inkludert hvor lenge prosessen har levd. Aktivitetsmonitor viser de samme opplysningene med et vennligere ansikt. Legg til kontrolløren, altså programmet eller tjenesten som har ansvaret for å starte og stoppe den. Med disse fire slutter en prosess å være et navn og blir et objekt du kan resonnere om.

Hvis én av de fire er ukjent, stopper du der. En ukjent komponent er et spørsmål for utgiveren eller administratoren, ikke et eksperiment.

PID-en i en gammel logg tilhører noen andre nå

Prosess-ID-er gjenbrukes, og et nummer som er kopiert fra gårsdagens logg, kan nå peke på noe helt urelatert. Sammenlign starttiden med tidsstempelet i loggen før du trekker noen konklusjon. Det samme gjelder et kortnavn: to utgaver av ett produkt kan levere hjelpere med identiske navn og ulike formål. Identitet er tuppelen, aldri nummeret alene.

Skill rollene før du rører noe annet. En klient for én tilkobling, en delt hjelper som betjener flere programmer, og en server som tar imot andres økter ser alle ut som en bakgrunnsprosess i en liste. Bare én av dem kan stoppes uten konsekvenser du ikke har vurdert.

Stopp gjennom eieren, ikke gjennom signalet

Begynn med kontrollen som eier tingen: Koble fra-knappen til tilkoblingen, tjenestens støttede stoppkommando, eller administrasjonsagentens egen handling. Disse veiene kjører nedrivingen produktet forventer, som inkluderer å fjerne ruter og lukke tunnelenheten. Et signal hopper over alt dette og etterlater tilstand.

Se på det som blir igjen etterpå. En prosess som blir boende, kan vente på neste tilkobling, noe som er et designvalg og ikke et mislykket stopp.

Hvorfor en overvåker starter på nytt det du drepte

Hvis en launch-daemon eller en automatisk tilkoblingspolicy vil at tunnelen skal være oppe, uttrykker det ingenting å drepe prosessen. Overvåkeren ser avslutningen og starter den igjen, noen ganger før du er ferdig med å lese loggen.

Finn overvåkeren før du kjemper mot den. launchctl list viser innlastede jobber og etikettene deres, og en jobb med keep-alive-innstilling starter på nytt ved avslutning, slik den er designet for. Riktig handling der er å endre intensjonen: last ut jobben, slå av den automatiske tilkoblingspolicyen, eller be administratoren gjøre det. Tvangslukking er et annet verktøy med en annen betydning, og den hører til en dokumentert gjenopprettingsprosedyre for en fastlåst prosess, ikke til vanlig tilkoblingsadministrasjon.

Registrer livssyklushendelsen, ikke drapet

Skriv ned komponentens identitet, klientversjonen, den første relevante livssyklushendelsen og hva du gjorde. Hendelsen betyr mer enn handlingen, fordi to instanser som dukker opp ved pålogging er et oppstartsrekkefølgeproblem som vil gjenta seg. En registrering som navngir den kjørbare filen og kontrolløren, lar neste person reprodusere det.

Kontroller deretter den tiltenkte tilstanden: tjenesten brukeren trengte, og den private ressursen den når. Unngå pipelinen som griper tak i en delstreng og tvangslukker hvert treff, siden den kaster alt det ovenstående og vanligvis ødelegger beviset for hvorfor to instanser fantes. Hvis prosessen stadig kommer tilbake, er funnet en konfigurasjons- eller rekkefølgefeil, og rettelsen hører hos den som eier klientens oppstartsatferd.