Identifiser Mac-VPN-hjelparen før du avsluttar prosessen

Behandle ei melding om ein hjelpar som alt køyrer som eit livssyklusspor, ikkje som løyve til å byrje å drepe prosessar. Det farlege steget er ikkje stoppen i seg sjølv, men identifiseringa føre han, fordi fleire komponentar med liknande namn kan finnast på same Mac, og berre éin av dei eig tilkoplinga. Bygg identitetsregisteret først. Deretter avgjer du om ein stopp i det heile er riktig handling.

Bygg eit identitetsregister før du handlar

Fire fakta gjer ein prosess identifiserbar: gjeldande PID med starttid, køyrbar fil og produktet han høyrer til, brukaren eller privilegiekonteksten han køyrer under, og det som starta han. ps -o pid,ppid,user,etime,command -p 1234 gir deg dei tre første på éi linje, inkludert kor lenge prosessen har levd. Aktivitetsmonitor viser dei same opplysningane med eit venlegare andlet. Legg til kontrolløren, altså programmet eller tenesta som har ansvaret for å starte og stoppe han. Med desse fire sluttar ein prosess å vere eit namn og blir eit objekt du kan resonnere om.

Viss éin av dei fire er ukjend, stoppar du der. Ein ukjend komponent er eit spørsmål for utgivaren eller administratoren, ikkje eit eksperiment.

PID-en i ein gammal logg høyrer til nokon andre no

Prosess-ID-ar blir gjenbrukte, og eit nummer som er kopiert frå gårsdagens logg, kan no peike på noko heilt urelatert. Samanlikn starttida med tidsstempelet i loggen før du dreg noka slutning. Det same gjeld eit kortnamn: to utgåver av eitt produkt kan levere hjelparar med identiske namn og ulike føremål. Identitet er tuppelen, aldri nummeret åleine.

Skil rollene før du rører noko anna. Ein klient for éi tilkopling, ein delt hjelpar som tener fleire program, og ein tenar som tek imot øktene til andre ser alle ut som ein bakgrunnsprosess i ei liste. Berre éin av dei kan stoppast utan konsekvensar du ikkje har vurdert.

Stopp gjennom eigaren, ikkje gjennom signalet

Byrj med kontrollen som eig tingen: Kople frå-knappen til tilkoplinga, den støtta stoppkommandoen til tenesta, eller handlinga til administrasjonsagenten sjølv. Desse vegane køyrer nedrivinga produktet ventar, som omfattar å fjerne ruter og lukke tunneleininga. Eit signal hoppar over alt dette og lèt tilstand bli att.

Sjå på det som blir att etterpå. Ein prosess som blir buande, kan vente på neste tilkopling, noko som er eit designval og ikkje ein mislukka stopp.

Kvifor ein overvakar startar på nytt det du drap

Viss ein launch-daemon eller ein automatisk tilkoplingspolicy vil at tunnelen skal vere oppe, uttrykkjer det ingenting å drepe prosessen. Overvakaren ser avslutninga og startar han igjen, av og til før du er ferdig med å lese loggen.

Finn overvakaren før du kjempar mot han. launchctl list viser innlasta jobbar og etiketta deira, og ein jobb med keep-alive-innstilling startar på nytt ved avslutning, slik han er designa for. Riktig handling der er å endre intensjonen: last ut jobben, slå av den automatiske tilkoplingspolicyen, eller be administratoren gjere det. Tvangslukking er eit anna verktøy med ei anna tyding, og ho høyrer til ein dokumentert gjenopprettingsprosedyre for ein fastlåst prosess, ikkje til vanleg tilkoplingsadministrasjon.

Registrer livssyklushendinga, ikkje drapet

Skriv ned identiteten til komponenten, klientversjonen, den første relevante livssyklushendinga og kva du gjorde. Hendinga tyder meir enn handlinga, fordi to instansar som dukkar opp ved pålogging er eit oppstartsrekkjefølgjeproblem som vil gjenta seg. Ei registrering som namngir den køyrbare fila og kontrolløren, lèt neste person reprodusere det.

Kontroller deretter den tiltenkte tilstanden: tenesta brukaren trong, og den private ressursen ho når. Unngå pipelinen som grip tak i ein delstreng og tvangslukkar kvart treff, sidan han kastar alt det ovanståande og vanlegvis øydelegg provet på kvifor to instansar fanst. Viss prosessen stadig kjem tilbake, er funnet ein konfigurasjons- eller rekkjefølgjefeil, og rettinga høyrer hos den som eig oppstartsåtferda til klienten.