Czy systemd wykryje i zabije zawieszone procesy?

Podczas pracy nad rozwiązaniem, które wykorzystuje blokowanie plików, uważam, że mój kod staje się martwy. Używam systemd, aby rozpocząć proces uruchamiania systemu. Używanie alarmu (3) jest opcją, ale zastanawiałem się, czy istnieje sposób, aby systemd wykrył zawieszone procesy i ponownie je uruchomił?

Obecnie, aby na razie obejść ten problem, zamierzam przyjrzeć się wynikom dziennika i jeśli nie zmieni się to przez określony czas, zabiłbym ten proces za pomocą skryptu powłoki.

Zastanawiam się tylko, czy istnieje lepszy sposób monitorowania procesów poprzez systemd lub w inny sposób.

monitoring systemd

— freethinker
źródło

Prawdopodobnie nie. Jak stwierdzić, czy proces się zawiesił? Co jeśli ty naprawdę potrzebuję czegoś takiego for(;;) do_something();?

— mvp

Ściśle mówiąc, jeśli twój kod się zawiesza, powinieneś debugować ten problem. Zabicie go przez systemd (zakładając, że można to zrobić, czego nie wierzę) lub w jakikolwiek inny sposób jest właściwym rozwiązaniem, gdy go debugujesz. Ale po prostu nie możesz zostawić go wolnemu, aby wejść w impas.

— MariusMatutiae

Tak; ale najpierw napraw swój buggy program przed manipulowaniem systememd.

MariusMatutiae ma rację. Masz problem ze swoim programem. To blokuje. Manipulowanie systemem nie jest odpowiedzią. W najlepszym razie jest to rozproszenie uwagi. Napraw swój program, aby nie był uszkodzony. Skieruj swoje energie na właściwe rzeczy.

To powiedziawszy, inni ludzie przyjdą tutaj z powodu tytułu pytania, a nie właściwego pytania. Dla ich korzyści, oto odpowiedź na tytuł, ignorując pytanie właściwe:

Tak, systemd może monitorować demony i automatycznie je ponownie uruchamiać, jeśli przestaną mówić. Jednak nie tylko stare demony. Jak zauważa mvp, nie ma sposobu, aby wiedzieć, że demon zawisł (w tym wszechświecie, gdzie problem z zatrzymaniem jest przynajmniej nierozstrzygalny). Ani systemowy, ani żaden inny program komputerowy nigdy nie będzie w stanie wydedukować od zera, że jakiś losowy program, który został na nich rzucony, jest zakleszczony lub trafił do nieskończonej pętli, lub cokolwiek innego. Najlepsze, co tu dostaniesz, to wykrycie, że demon nie przeprowadził regularnej operacji „bicia serca” w wymaganym czasie.

Dlatego demony, które wykorzystują możliwości watchdoga systemd, muszą być napisane, aby mówić protokołem specyficznym dla systemu, czyli protokołem sd_notify. To komplikuje kod demona. Jest to bardziej skomplikowane, ponieważ dæmons powinny, jeśli zostaną poprawnie napisane, sprawdzić, czy zostały wywołane z włączoną funkcją watchdog.

Demona, który mówi tym protokołem, aby skorzystać z możliwości watchdoga systemd…

… Musi sprawdzić WATCHDOG_USEC Zmienna środowiskowa;
… Musi zadzwonić sd_notify () stale i często, przez całe życie, z WATCHDOG=1 zestaw opcji w odstępie około WATCHDOG_USEC / 2 („USEC” oznacza mikrosekundy);
… muszę mieć Type=notify ustawione w pliku jednostki;
… Powinien NotifyAccess=main (lub =all ) ustawiony w pliku jednostki;
… muszę mieć WatchdogSec= sekundy ustawić w pliku jednostki.
… Musi się połączyć libsystemd-daemon.so

Jeśli chcesz poznać szczegóły tego kodowania, po przeczytaniu podręcznika upewnij się, że idziesz do właściwego StackExchange. To jest SuperUser. StackOverflow jest tam .

Dalsza lektura

Lennart Poettering. 2011-04-12. Strażnicy . Freedesktop.org.

— JdeBP
źródło

Oczywiście, muszę rozwiązać ten problem, moim jedynym zamiarem było tymczasowe włamanie do czasu, aż zrozumiem problem. Dziękujemy za szczegółową odpowiedź.

— freethinker