Определите вспомогательный процесс VPN на Mac до его остановки
Сопоставьте процесс VPN с его исполняемым файлом, контроллером и сетевой ролью, прежде чем останавливать его, а затем используйте штатный путь остановки владельца, а не сигнал.
Сообщение о вспомогательном процессе, который уже запущен, воспринимайте как подсказку о жизненном цикле, а не как разрешение начинать убивать процессы. Опасен здесь не сам останов, а идентификация перед ним: на одном Mac могут существовать несколько компонентов с похожими именами, и только один из них владеет соединением. Сначала составьте запись идентичности. Затем решите, является ли остановка вообще правильным действием.
Составьте запись идентичности, прежде чем действовать
Процесс делают опознаваемым четыре факта: текущий PID со временем запуска, исполняемый файл и продукт, к которому он относится, пользователь или контекст привилегий, под которым он работает, и то, что его запустило. ps -o pid,ppid,user,etime,command -p 1234 выдаёт первые три в одной строке, включая время жизни процесса. Монитор активности показывает те же сведения в более удобном виде. Добавьте контроллер, то есть приложение или службу, отвечающую за его запуск и остановку. С этими четырьмя процесс перестаёт быть именем и становится объектом, о котором можно рассуждать.
Если один из четырёх неизвестен, остановитесь на этом. Незнакомый компонент — вопрос к издателю или администратору, а не эксперимент.
PID из старого журнала теперь принадлежит кому-то другому
Идентификаторы процессов переиспользуются, и номер, скопированный из вчерашнего журнала, может теперь указывать на нечто совершенно постороннее. Сравните время запуска с отметкой времени в журнале, прежде чем делать вывод. То же относится к короткому имени: две сборки одного продукта могут поставлять вспомогательные процессы с одинаковыми именами и разным назначением. Идентичность — это кортеж, а не одно лишь число.
Разделите роли, прежде чем трогать что-либо ещё. Клиент одного соединения, общий помощник, обслуживающий несколько приложений, и сервер, принимающий чужие сеансы, в списке выглядят одинаково — как фоновый процесс. Только один из них можно остановить без последствий, которые вы не учли.
Останавливайте через владельца, а не через сигнал
Начните с элемента управления, которому принадлежит вещь: кнопки отключения в соединении, поддерживаемой команды остановки службы или собственного действия агента управления. Эти пути выполняют демонтаж, которого ожидает продукт, включая удаление маршрутов и закрытие туннельного устройства. Сигнал пропускает всё это и оставляет состояние после себя.
Посмотрите, что остаётся после этого. Процесс, который остался в памяти, может ждать следующего соединения, и это выбор проектирования, а не неудачная остановка.
Почему супервизор перезапускает то, что вы убили
Если демон запуска или политика автоподключения хочет, чтобы туннель был поднят, убийство процесса ничего не выражает. Супервизор видит завершение и запускает его снова, иногда прежде чем вы дочитаете журнал.
Найдите супервизор, прежде чем с ним бороться. launchctl list показывает загруженные задания и их метки, а задание с параметром keep-alive перезапускается при завершении — так задумано. Правильное действие здесь — изменить намерение: выгрузить задание, отключить политику автоподключения или попросить об этом администратора. Принудительное завершение — другой инструмент с другим смыслом, и он относится к документированной процедуре восстановления зависшего процесса, а не к повседневному управлению соединениями.
Записывайте событие жизненного цикла, а не убийство
Запишите идентичность компонента, версию клиента, первое значимое событие жизненного цикла и то, что вы сделали. Событие важнее действия, потому что два экземпляра, появляющиеся при входе в систему, — это проблема порядка запуска, которая повторится. Запись с указанием исполняемого файла и его контроллера позволит следующему человеку воспроизвести её.
Затем проверьте предполагаемое состояние: службу, которая была нужна пользователю, и частный ресурс, до которого она достаёт. Избегайте конвейера, который ищет подстроку и принудительно убивает каждое совпадение: он отбрасывает всё перечисленное выше и обычно уничтожает доказательство того, почему существовали два экземпляра. Если процесс продолжает возвращаться, находка — дефект конфигурации или порядка, и исправление принадлежит тому, кто отвечает за поведение клиента при запуске.