Nasz watchdog uruchomił ponownie usługi, które celowo zatrzymaliśmy

Operacje2026-10-31

Jeden z naszych watchdogów uruchamia każdą z naszych usług, która jest włączona, ale nie działa. Dwa razy w październiku uruchomił usługi, które celowo zatrzymaliśmy. Za drugim razem odwiedzający jedną z naszych stron otrzymywali błędy przez około 45 minut.

Dlaczego ten watchdog istnieje

Usługa, która kończy działanie poprawnie po otrzymaniu sygnału SIGTERM, na przykład dlatego, że coś ją zabiło po nazwie, nie jest „nieudana” z punktu widzenia systemd. Restart=on-failure jej nie przywraca, a systemctl --failed jej nie wyświetla. Pozostaje wyłączona, dopóki ktoś przypadkiem tego nie zauważy. Dlatego watchdog szuka usług, które są włączone, ale nie działają, i je uruchamia.

Problem polega na tym, że usługa zatrzymana ręcznie wygląda dokładnie tak samo.

Pierwszy raz

7 października zatrzymaliśmy proces roboczy wideo za pomocą systemctl stop o 12:47, aby edytować jego kolejkę zadań. O 12:55 działał ponownie: watchdog go uruchomił.

Drugi raz

21 października potrzebowaliśmy pamięci maszyny, która obsługuje również dwie z naszych stron, do testu modelu. Skrypt zatrzymał aplikacje webowe stron, zadanie synchronizacji i kontener bazy danych, ponownie za pomocą systemctl stop. Około pięć minut później timer nadzorujący strony, a o 19:14 watchdog, przywróciły tunel i aplikacje webowe.

Tunel zaczął ponownie przyjmować ruch, ale aplikacje webowe nie mogły odpowiadać: testowany model zajmował 114 GiB pamięci maszyny. Od około 19:14 do 20:00 niektórzy odwiedzający otrzymywali błędy 502. O 20:00 wyłączyliśmy tunel, aplikacje webowe i zadanie synchronizacji oraz zatrzymaliśmy timer nadzoru.

Zasada, którą teraz stosujemy

• Wstrzymaj usługę, wyłączając ją: sudo systemctl disable --now <unit>. Przywróć ją za pomocą sudo systemctl enable --now <unit>. Nasz watchdog sprawdza tylko usługi włączone, więc wyłączone zostawia w spokoju.
• Wstrzymaj wszystko, co może ją przywrócić: tunel przed nią i każdy timer, który ją nadzoruje.
• Krótkie zatrzymanie to wyścig z czasem. Jeśli używasz tylko stop, zakończ przed następnym sprawdzeniem, które na naszych maszynach następuje w ciągu kilku minut.

Dwie kolejne pułapki systemd z tych samych miesięcy

• systemctl mask --runtime nic nie robi dla pliku unit w /etc/systemd/system. Unity w /etc mają priorytet nad maską runtime w /run, więc polecenie kończy się sukcesem, a usługa nadal startuje. Aby wstrzymać usługę, używamy drop-in z ConditionPathExists=!/etc/<name>.hold: dopóki ten plik istnieje, usługa nie wystartuje, ani przy rozruchu, ani ręcznie.
• systemctl is-active zgłasza działającą usługę oneshot jako nieaktywną. Podczas gdy usługa Type=oneshot działa, jej stan to "activating", więc is-active wypisuje tę wartość i zwraca 3. Pętla typu while systemctl is-active --quiet job.service; do sleep 60; done, mająca czekać na nocne zadanie, kończy się natychmiast. Zamiast tego czytaj stan: active, activating, reloading lub deactivating oznaczają, że usługa nadal działa.

Factory Floor obserwuje włączone usługi, które nie działają. Domyślnie tylko je raportuje, a uruchamia je tylko wtedy, gdy to włączysz. Od wersji 1.0.3 jego alert mówi też, jak celowo wstrzymać usługę, a jego runbook mówi to samo.