Zidentyfikuj pomocnik VPN na Macu, zanim zakończysz proces
Dopasuj proces VPN do jego pliku wykonywalnego, kontrolera i roli sieciowej, zanim go zatrzymasz, a potem użyj ścieżki zatrzymania właściciela, a nie sygnału.
Komunikat o pomocniku, który już działa, traktuj jako wskazówkę dotyczącą cyklu życia, a nie zgodę na zabijanie procesów. Niebezpiecznym krokiem nie jest samo zatrzymanie, lecz identyfikacja przed nim, ponieważ na jednym Macu może istnieć kilka składników o podobnych nazwach i tylko jeden z nich jest właścicielem połączenia. Najpierw zbuduj rekord tożsamości. Potem zdecyduj, czy zatrzymanie jest w ogóle właściwym działaniem.
Zbuduj rekord tożsamości, zanim zaczniesz działać
Cztery fakty czynią proces identyfikowalnym: bieżący PID z czasem rozpoczęcia, plik wykonywalny i produkt, do którego należy, użytkownik lub kontekst uprawnień, w którym działa, oraz to, co go uruchomiło. ps -o pid,ppid,user,etime,command -p 1234 podaje pierwsze trzy w jednym wierszu, wraz z tym, jak długo proces już żyje. Monitor aktywności pokazuje te same informacje w przystępniejszej formie. Dodaj kontrolera, czyli aplikację lub usługę odpowiedzialną za jego uruchamianie i zatrzymywanie. Z tymi czterema proces przestaje być nazwą i staje się obiektem, o którym można rozumować.
Jeśli któryś z tych czterech jest nieznany, zatrzymaj się w tym miejscu. Nieznany składnik to pytanie do wydawcy lub administratora, a nie eksperyment.
PID w starym logu należy teraz do kogoś innego
Identyfikatory procesów są wykorzystywane ponownie, a numer skopiowany z wczorajszego logu może teraz wskazywać na coś całkowicie niezwiązanego. Porównaj czas rozpoczęcia ze znacznikiem czasu w logu, zanim wyciągniesz jakikolwiek wniosek. To samo dotyczy krótkiej nazwy: dwie kompilacje jednego produktu mogą dostarczać pomocniki o identycznych nazwach i różnych celach. Tożsamością jest krotka, nigdy sam numer.
Rozdziel role, zanim czegokolwiek innego dotkniesz. Klient jednego połączenia, współdzielony pomocnik obsługujący kilka aplikacji i serwer przyjmujący sesje innych osób wyglądają na liście jak zwykły proces w tle. Tylko jeden z nich można zatrzymać bez skutków, których nie przewidziałeś.
Zatrzymuj przez właściciela, nie przez sygnał
Zacznij od elementu sterującego, który jest właścicielem rzeczy: przycisku Rozłącz połączenie, obsługiwanego polecenia zatrzymania usługi albo własnej akcji agenta zarządzającego. Te ścieżki wykonują demontaż, którego oczekuje produkt, obejmujący usuwanie tras i zamykanie urządzenia tunelowego. Sygnał pomija to wszystko i zostawia po sobie stan.
Obserwuj, co pozostaje po wszystkim. Proces, który pozostaje w pamięci, może czekać na następne połączenie, co jest wyborem projektowym, a nie nieudanym zatrzymaniem.
Dlaczego nadzorca uruchamia ponownie to, co zabiłeś
Jeśli demon uruchamiający lub zasada automatycznego łączenia chce, aby tunel był aktywny, zabicie procesu niczego nie wyraża. Nadzorca widzi zakończenie i uruchamia go ponownie, czasami zanim skończysz czytać log.
Znajdź nadzorcę, zanim zaczniesz z nim walczyć. launchctl list pokazuje załadowane zadania i ich etykiety, a zadanie z ustawieniem keep-alive uruchamia się ponownie po zakończeniu, zgodnie z projektem. Właściwym działaniem jest tam zmiana intencji: wyładuj zadanie, wyłącz zasadę automatycznego łączenia lub poproś o to administratora. Wymuszone zakończenie to inne narzędzie o innym znaczeniu i należy do udokumentowanej procedury odzyskiwania dla zawieszonego procesu, a nie do rutynowego zarządzania połączeniami.
Zapisuj zdarzenie cyklu życia, a nie zabicie
Zapisz tożsamość składnika, wersję klienta, pierwsze istotne zdarzenie cyklu życia i to, co zrobiłeś. Zdarzenie ma większe znaczenie niż działanie, ponieważ dwie instancje pojawiające się przy logowaniu to problem kolejności uruchamiania, który będzie się powtarzał. Rekord nazywający plik wykonywalny i jego kontrolera pozwala następnej osobie to odtworzyć.
Następnie sprawdź zamierzony stan: usługę, której użytkownik potrzebował, i zasób prywatny, do którego ona dociera. Unikaj potoku, który wyszukuje podciąg i wymuszenie zabija każde trafienie, ponieważ odrzuca on wszystko powyższe i zwykle niszczy dowód, dlaczego istniały dwie instancje. Jeśli proces wciąż wraca, ustaleniem jest defekt konfiguracji lub kolejności, a poprawka należy do tego, kto odpowiada za zachowanie startowe klienta.