Визначте допоміжний процес VPN на Mac до його зупинки

Повідомлення про допоміжний процес, який уже працює, сприймайте як підказку про життєвий цикл, а не як дозвіл починати вбивати процеси. Небезпечним тут є не сама зупинка, а ідентифікація перед нею, бо на одному Mac можуть існувати кілька компонентів зі схожими назвами і лише один із них володіє з'єднанням. Спершу складіть запис ідентичності. Потім вирішіть, чи зупинка взагалі є правильною дією.

Складіть запис ідентичності, перш ніж діяти

Чотири факти роблять процес упізнаваним: поточний PID із часом запуску, виконуваний файл і продукт, до якого він належить, користувач або контекст привілеїв, під яким він працює, і те, що його запустило. ps -o pid,ppid,user,etime,command -p 1234 дає перші три в одному рядку, включно з тим, як довго процес живе. Монітор активності показує ті самі відомості в зручнішому вигляді. Додайте контролер, тобто застосунок або службу, відповідальну за його запуск і зупинку. З цими чотирма процес перестає бути назвою і стає об'єктом, про який можна міркувати.

Якщо один із чотирьох невідомий, зупиніться на цьому. Незнайомий компонент — питання до видавця або адміністратора, а не експеримент.

PID у старому журналі тепер належить комусь іншому

Ідентифікатори процесів перевикористовуються, і номер, скопійований із учорашнього журналу, може тепер указувати на щось цілком стороннє. Порівняйте час запуску з позначкою часу в журналі, перш ніж робити будь-який висновок. Те саме стосується короткої назви: дві збірки одного продукту можуть постачати допоміжні процеси з однаковими назвами й різним призначенням. Ідентичність — це кортеж, а не саме лише число.

Розділіть ролі, перш ніж торкатися чогось іншого. Клієнт одного з'єднання, спільний помічник, що обслуговує кілька застосунків, і сервер, який приймає чужі сеанси, у списку виглядають однаково — як фоновий процес. Лише один із них можна зупинити без наслідків, яких ви не врахували.

Зупиняйте через власника, а не через сигнал

Почніть із елемента керування, якому належить річ: кнопки від'єднання в з'єднанні, підтримуваної команди зупинки служби або власної дії агента керування. Ці шляхи виконують демонтаж, якого очікує продукт, зокрема видалення маршрутів і закриття тунельного пристрою. Сигнал усе це пропускає й залишає стан по собі.

Подивіться, що залишається після цього. Процес, який залишився в пам'яті, може чекати наступного з'єднання, і це вибір проєктування, а не невдала зупинка.

Чому супервізор перезапускає те, що ви вбили

Якщо демон запуску або політика автопідключення хоче, щоб тунель був піднятий, убивство процесу нічого не виражає. Супервізор бачить завершення і запускає його знову, іноді перш ніж ви дочитаєте журнал.

Знайдіть супервізор, перш ніж з ним боротися. launchctl list показує завантажені завдання та їхні мітки, а завдання з налаштуванням keep-alive перезапускається після завершення — так задумано. Правильна дія тут — змінити намір: вивантажити завдання, вимкнути політику автопідключення або попросити про це адміністратора. Примусове завершення — інший інструмент з іншим змістом, і він належить до документованої процедури відновлення завислого процесу, а не до повсякденного керування з'єднаннями.

Записуйте подію життєвого циклу, а не вбивство

Запишіть ідентичність компонента, версію клієнта, першу значущу подію життєвого циклу і те, що ви зробили. Подія важливіша за дію, бо два екземпляри, що з'являються під час входу, — це проблема порядку запуску, яка повториться. Запис із зазначенням виконуваного файлу та його контролера дозволить наступній людині відтворити це.

Потім перевірте передбачуваний стан: службу, яка була потрібна користувачеві, і приватний ресурс, до якого вона дістає. Уникайте конвеєра, який шукає підрядок і примусово вбиває кожен збіг, бо він відкидає все перелічене вище і зазвичай знищує доказ того, чому існували два екземпляри. Якщо процес продовжує повертатися, знахідка — дефект конфігурації або порядку, і виправлення належить тому, хто відповідає за поведінку клієнта під час запуску.