Czy skrypt up OpenVPN uruchomił się zbyt wcześnie, czy nigdy nie był gotowy?

Skrypt up uruchamia się, kończy z kodem zero, a zadanie w nim nie dociera do prywatnej usługi, która z terminala działa idealnie dwie sekundy później. Instynkt podpowiada czas, a zwykłą naprawą jest uśpienie, które ukrywa wyścig, nie rozumiejąc go. Użyteczniejsze odczytanie jest takie, że “up” nazywa hak, a nie gwarancję gotowości. Odpala się, gdy urządzenie tunelu jest skonfigurowane, czyli wcześniej niż trasy, DNS i z pewnością wcześniej niż jakakolwiek aplikacja za tunelem.

Test w powłoce się powiódł, bo uruchomił się po tym, jak wszystko się uspokoiło. Hak uruchomił się w jednym konkretnym momencie.

Gdzie up znajduje się w kolejności startu

OpenVPN konfiguruje urządzenie tunelu, a następnie uruchamia hak up. Instalacja tras to późniejszy etap i ma własny hak, dlatego zadanie zależne od tras umieszczone w up może zobaczyć urządzenie bez użytecznej ścieżki. Umieść pracę z trasami w route-up, a problem z czasem zwykle znika.

Podręcznik dokumentuje tę kolejność i środowisko, które otrzymuje każdy hak. Ta kolejność to całe wyjaśnienie klasycznego raportu “działa z mojej powłoki”, a także powód, dla którego ten sam skrypt może przejść na jednej maszynie i zawieść na innej z wolniejszym etapem tras. Żaden z wyników nie mówi nic o jakości skryptu.

DNS i gotowość aplikacji przychodzą jeszcze później. Nawet zainstalowane trasy nie są dowodem, że zdalny punkt końcowy nasłuchuje, że nazwa się rozwiązuje, ani że istnieje sesja pulpitu dla zadania w zakresie użytkownika.

Co hak faktycznie dziedziczy

Hak działa na koncie i w środowisku procesu OpenVPN, co nie jest tym samym co twoja interaktywna powłoka. Może mu brakować magistrali sesji użytkownika, środowiska pulpitu lub poświadczenia odblokowywanego tylko przy logowaniu. Zapisz, czego z tego zadanie naprawdę potrzebuje.

To ma znaczenie dla zadań, które wyglądają sieciowo, ale zależą od kontekstu użytkownika: montowanie udziału z poświadczeniem użytkownika, ustawianie proxy dla użytkownika lub konfigurowanie drukarki. Uprzywilejowany hak tunelu to złe miejsce dla nich, a żadne czekanie nie naprawi brakującej sesji.

Gdy zadanie zawodzi w haku, zapisz konto, środowisko i pierwszą operację, która zawiodła. To oddziela zbyt wczesny czas od problemu z uprawnieniami lub kontekstem, a te dwa mają zupełnie różne naprawy. Zgadywanie między nimi to sposób, w jaki pięciominutowa poprawka staje się całym popołudniem.

Dlaczego dodanie uśpienia nie jest sprawdzeniem gotowości

Uśpienie opóźnia skrypt i przesuwa okno wyścigu. W szybki dzień zadanie się udaje; w wolny dzień znów zawodzi, a awarię trudniej odtworzyć, bo opóźnienie wydaje się działać. Opóźnienie, które działa tylko przy lekkim obciążeniu, to zbieg okoliczności, nie naprawa.

Jeśli zależnością jest trasa, użyj haka odpowiadającego instalacji tras. Jeśli zależnością jest usługa za tunelem, użyj ograniczonego sprawdzenia, które czeka na ten konkretny warunek i wyraźnie zawodzi, gdy nigdy nie nadchodzi.

Utrzymuj awarię jawną. Hak, który kończy się zerem, choć jego rzeczywista praca zawiodła, jest gorszy niż hak, który zawodzi, bo menedżer usług zapisuje sukces i nikt już nie patrzy. Jedna linia logu z samego skryptu to najtańszy sposób, by zachować to uczciwie.

Sprzątanie i ponowne połączenie zasługują na taką samą troskę

Skrypt, który zmienia stan współdzielony, potrzebuje pasującej ścieżki cofania. Trasy, wpisy resolvera i znaczniki firewalla dodane przez hak powinny być idempotentne i odwracalne, inaczej ponowne połączenie nałoży drugą kopię na pierwszą.

Ponowne połączenia mogą też uruchamiać haki częściej niż pełny start usługi. Trwały interfejs, który ponownie ustanawia sesję, może ponownie wywołać cykl up i route-up, więc skrypt zakładający jedno uruchomienie na boot w końcu zacznie działać źle. Policz uruchomienia w logu przez dzień migotania, aby zobaczyć, jak często naprawdę działa. Następnie uczyń skrypt bezpiecznym do uruchamiania tyle razy.

Testuj cykl życia, który zawiódł, a nie późniejsze polecenie. Odtwórz boot lub ponowne połączenie, obserwuj wykonanie haka i potwierdź, że zadanie powiodło się w momencie, w którym naprawdę się uruchamia. Sukces z interaktywnej powłoki później jest dowodem na temat zależności, nie dowodem, że ścieżka startu działa.

Nazwij zdarzenie, od którego zależy każde zadanie, a potem przypisz je do tego zdarzenia. Wszystko inne to opóźnienie udające sprawdzenie.