Kilalanin ang Mac VPN helper bago mo ihinto ang proseso
Itugma ang isang proseso ng VPN sa executable nito, controller at papel sa network bago ito ihinto, pagkatapos ay gamitin ang daan ng paghinto ng may-ari sa halip na signal.
Ituring ang mensahe tungkol sa helper na tumatakbo na bilang bakas ng lifecycle, hindi bilang pahintulot na magsimulang pumatay ng mga proseso. Ang mapanganib na hakbang ay hindi ang paghinto mismo kundi ang pagkakakilanlan bago iyon, dahil maaaring may ilang bahagi na may magkakatulad na pangalan sa isang Mac at isa lamang sa kanila ang may-ari ng koneksyon. Buuin muna ang talaan ng pagkakakilanlan. Pagkatapos ay magpasya kung ang paghinto ay ang tamang aksyon.
Buuin ang talaan ng pagkakakilanlan bago kumilos
Apat na katotohanan ang nagpapakilala sa isang proseso: ang kasalukuyang PID kasama ang oras ng pagsisimula, ang executable at produkto kung saan ito nabibilang, ang user o konteksto ng pribilehiyo kung saan ito tumatakbo, at ang nagsimula nito. ps -o pid,ppid,user,etime,command -p 1234 ay nagbibigay sa iyo ng unang tatlo sa isang linya, kasama kung gaano katagal nang buhay ang proseso. Ipinapakita ng Activity Monitor ang parehong impormasyon sa mas madaling paraan. Idagdag ang controller, ibig sabihin ang application o serbisyo na responsable sa pag-start at paghinto nito. Sa apat na iyon, ang isang proseso ay hindi na pangalan at nagiging bagay na maaari mong pangangatwiranan.
Kung ang isa sa apat ay hindi kilala, huminto doon. Ang hindi pamilyar na bahagi ay tanong para sa publisher o administrator, hindi eksperimento.
Ang PID sa lumang log ay pag-aari na ng iba ngayon
Ang mga ID ng proseso ay nire-recycle, at ang numerong kinopya mula sa log ng kahapon ay maaaring tumuro na ngayon sa isang bagay na walang kaugnayan. Ihambing ang oras ng pagsisimula sa timestamp ng log bago gumawa ng anumang konklusyon. Ganoon din sa maikling pangalan: dalawang build ng isang produkto ay maaaring maghatid ng mga helper na may magkaparehong pangalan at magkaibang layunin. Ang pagkakakilanlan ay ang tuple, hindi kailanman ang numero lamang.
Paghiwalayin ang mga papel bago hawakan ang anupaman. Ang kliyente ng isang koneksyon, isang shared helper na naglilingkod sa ilang application, at isang server na tumatanggap ng session ng iba ay mukhang background na proseso sa isang listahan. Isa lamang sa kanila ang maaaring ihinto nang walang mga kahihinatnan na hindi mo isinaalang-alang.
Ihinto sa pamamagitan ng may-ari, hindi sa pamamagitan ng signal
Magsimula sa kontrol na nagmamay-ari ng bagay: ang pindutan ng Disconnect ng koneksyon, ang sinusuportahang utos ng paghinto ng serbisyo, o ang sariling aksyon ng management agent. Ang mga daang ito ay nagpapatupad ng teardown na inaasahan ng produkto, na kasama ang pagtanggal ng mga ruta at pagsasara ng tunnel device. Ang signal ay lumalampas sa lahat ng iyon at nag-iiwan ng estado.
Tingnan kung ano ang natitira pagkatapos. Ang prosesong nananatili ay maaaring naghihintay sa susunod na koneksyon, na isang desisyon sa disenyo at hindi isang nabigong paghinto.
Bakit binubuksan muli ng supervisor ang pinatay mo
Kung nais ng launch daemon o patakaran ng auto-connect na tumatakbo ang tunnel, walang ipinapahayag ang pagpatay sa proseso. Nakikita ng supervisor ang paglabas at sinisimulan muli ito, kung minsan bago mo pa matapos basahin ang log.
Hanapin ang supervisor bago mo ito labanan. launchctl list ay nagpapakita ng mga naka-load na trabaho at kanilang mga label, at ang trabahong may keep-alive na setting ay nagsisimulang muli kapag lumabas, ayon sa disenyo. Ang tamang aksyon doon ay baguhin ang intensyon: i-unload ang trabaho, patayin ang patakaran ng auto-connect, o hilingin sa administrator na gawin iyon. Ang sapilitang pagpapatay ay ibang kasangkapan na may ibang kahulugan, at kabilang ito sa dokumentadong pamamaraan ng pagbawi para sa isang stuck na proseso, hindi sa regular na pamamahala ng koneksyon.
Itala ang kaganapan ng lifecycle, hindi ang pagpatay
Isulat ang pagkakakilanlan ng bahagi, ang bersyon ng kliyente, ang unang kaugnay na kaganapan ng lifecycle at ang ginawa mo. Ang kaganapan ay mas mahalaga kaysa sa aksyon, dahil ang dalawang instance na lumilitaw sa pag-log in ay problema sa pagkakasunod-sunod ng pagsisimula na mauulit. Ang talaan na nagpangalan sa executable at sa controller nito ay nagbibigay-daan sa susunod na tao na kopyahin ito.
Pagkatapos ay i-verify ang nilalayong estado: ang serbisyong kailangan ng user, at ang pribadong resource na naaabot nito. Iwasan ang pipeline na naghahanap ng substring at sapilitang pumapatay sa bawat tugma, dahil itinatapon nito ang lahat ng nabanggit sa itaas at karaniwang sinisira ang ebidensya kung bakit may dalawang instance. Kung patuloy na bumabalik ang proseso, ang natuklasan ay depekto sa configuration o pagkakasunod-sunod, at ang pag-aayos ay pag-aari ng may-ari ng pag-uugali ng pagsisimula ng kliyente.