Разпознайте помощника на VPN в Mac, преди да убиете процеса
Свържете процес на VPN с неговия изпълним файл, контролер и мрежова роля, преди да го спрете, после използвайте пътя за спиране на собственика, а не сигнал.
Отнасяйте се към съобщението за вече работещ помощник като към подсказка за жизнения цикъл, а не като към разрешение да започнете да убивате процеси. Опасната стъпка не е самото спиране, а идентификацията преди него, защото на един Mac могат да съществуват няколко компонента с подобни имена и само един от тях притежава връзката. Първо изградете записа за самоличност. След това решете дали спирането е правилното действие изобщо.
Изградете запис за самоличност, преди да действате
Четири факта правят един процес разпознаваем: текущият PID с времето му на стартиране, изпълнимият файл и продуктът, към който принадлежи, контекстът на потребителя или привилегиите, под които работи, и това, което го е стартирало. ps -o pid,ppid,user,etime,command -p 1234 ви дава първите три на един ред, включително колко дълго процесът е жив. Activity Monitor показва същата информация с по-приятелско лице. Добавете контролера, тоест приложението или услугата, отговорни за стартирането и спирането му. С тези четири процесът престава да бъде име и се превръща в обект, за който можете да разсъждавате.
Ако един от четирите е неизвестен, спрете дотам. Непознат компонент е въпрос към издателя или администратора, а не експеримент.
PID от стар журнал сега принадлежи на някой друг
Идентификаторите на процеси се рециклират и номер, копиран от вчерашния журнал, може сега да сочи към нещо напълно несвързано. Сравнете времето на стартиране с времевата марка на журнала, преди да правите каквото и да е заключение. Същото важи и за кратко име: две издания на един продукт могат да доставят помощници с еднакви имена и различни предназначения. Самоличността е кортежът, никога само номерът.
Разделете ролите, преди да пипате друго. Клиентът на една връзка, споделен помощник, обслужващ няколко приложения, и сървър, приемащ сесиите на други хора, всички изглеждат като фонов процес в списък. Само един от тях може да бъде спрян без последствия, които не сте обмислили.
Спирайте през собственика, а не през сигнала
Започнете с контрола, който притежава нещото: бутонът „Прекъсване“ на връзката, поддържаната команда за спиране на услугата или собственото действие на агента за управление. Тези пътища изпълняват демонтажа, който продуктът очаква, включително премахване на маршрути и затваряне на устройството на тунела. Сигналът пропуска всичко това и оставя състояние след себе си.
Наблюдавайте какво остава след това. Процес, който остава в паметта, може да чака следващата връзка, което е избор на дизайн, а не неуспешно спиране.
Защо супервизорът рестартира това, което сте убили
Ако launch демон или политика за автоматично свързване предвижда тунелът да е активен, убиването на процеса не изразява нищо. Супервизорът вижда изхода и го стартира отново, понякога преди да сте дочели журнала.
Намерете супервизора, преди да се борите с него. launchctl list показва заредените задачи и техните етикети, а задача с настройка за поддържане на живо се рестартира при изход по дизайн. Правилното действие там е да промените намерението: разтоварете задачата, изключете политиката за автоматично свързване или помолете администратора да го направи. Принудителното затваряне е различен инструмент с различно значение и принадлежи към документирана процедура за възстановяване на заклещен процес, а не към рутинното управление на връзки.
Запишете събитието от жизнения цикъл, а не убийството
Запишете самоличността на компонента, версията на клиента, първото значимо събитие от жизнения цикъл и какво сте направили. Събитието е по-важно от действието, защото два екземпляра, появяващи се при вход, са проблем с реда на стартиране, който ще се повтаря. Запис, който назовава изпълнимия файл и неговия контролер, позволява на следващия човек да го възпроизведе.
След това проверете предвиденото състояние: услугата, от която потребителят се нуждаеше, и частния ресурс, който тя достига. Избягвайте конвейера, който търси подниз и принудително убива всяко съвпадение, защото той изхвърля всичко гореизброено и обикновено унищожава доказателството защо са съществували два екземпляра. Ако процесът продължава да се връща, откритието е дефект в конфигурацията или подредбата и поправката принадлежи на този, който притежава поведението при стартиране на клиента.