Può systemd rilevare e uccidere processi sospesi?

Mentre sto lavorando su una soluzione che utilizza il blocco dei file, credo che il mio codice stia entrando in una fase di stallo. Sto usando systemd per avviare il processo all'avvio del sistema. Usare alarm (3) è un'opzione, ma mi chiedevo se c'è un modo per systemd per rilevare i processi sospesi e riavviarli?

Attualmente per aggirare questo problema per ora, ho intenzione di guardare l'output di journalctl e se non cambia per un periodo di tempo specificato, allora ucciderei il processo attraverso uno script di shell.

Mi chiedo solo se c'è un modo migliore per monitorare i processi attraverso systemd o in altro modo.

monitoring systemd

— freethinker
fonte

Probabilmente no. Come si dice se il processo è bloccato? E se tu veramente bisogno di qualcosa come for(;;) do_something();?

— mvp

A rigor di termini, se il codice si blocca, è necessario eseguire il debug del problema. Ucciderlo via systemd (supponendo che possa essere fatto, cosa che non credo) o in qualsiasi altro modo è la cosa giusta da fare mentre lo fai il debug. Ma non puoi lasciarlo libero di andare in una situazione di stallo.

— MariusMatutiae

Sì; ma prima aggiusta il tuo programma buggy prima di armeggiare con systemd.

MariusMatutiae è abbastanza corretta. Hai un problema con il tuo programma. È deadlock. Giocherellare con systemd non è la risposta. Nella migliore delle ipotesi, è una distrazione. Correggi il tuo programma in modo che non sia rotto. Dirigi le tue energie con la cosa giusta.

Detto questo, altre persone verranno qui a causa del titolo della domanda, piuttosto che della domanda vera e propria. A loro vantaggio, ecco la risposta al titolo, ignorando la domanda vera e propria:

Sì, systemd può monitorare i demoni e riavviarli automaticamente se smettono di parlare. Ma non tutti i vecchi demoni. Come nota la MVP, non c'è modo di sapere che un demone è stato appeso (in questo universo, dove il problema della fermata è indecidibile, almeno). Né systemd né alcun altro programma per computer saranno mai in grado di dedurre da zero che un programma casuale lanciato su di essi ha un deadlock, o è finito in un loop infinito, o qualsiasi altra cosa. Il meglio che otterrete qui è la rilevazione che un demone non ha eseguito una normale operazione "battito cardiaco" entro un intervallo di tempo richiesto.

I demoni che sfruttano le capacità di watchdog di systemd, pertanto, devono essere scritti per parlare di un protocollo systemd-specific, il protocollo sd_notify. Questo complica un po 'il codice dei demoni. È complicato perché i demoni dovrebbero, se scritti correttamente, controllare se sono stati richiamati anche con la funzione di watchdog abilitata.

Un demone che parla questo protocollo per utilizzare la capacità di watchdog di systemd ...

... deve controllare per WATCHDOG_USEC variabile d'ambiente;
... deve chiamare sd_notify () continuamente e frequentemente, per tutta la sua vita, con il WATCHDOG=1 opzione impostata, ad un intervallo di circa WATCHDOG_USEC / 2 ("USEC" sta per microsecondi);
… deve avere Type=notify impostato nel suo file unitario;
… avrebbe dovuto NotifyAccess=main (o =all ) impostato nel suo file unitario;
… deve avere WatchdogSec= secondi impostato nel suo file di unità.
... deve collegarsi con libsystemd-daemon.so

Se vuoi conoscere i dettagli della codifica, dopo aver letto il manuale, assicurati di andare sul StackExchange giusto. Questo è SuperUser. StackOverflow è laggiù .

Ulteriori letture

Lennart Poettering. 2011-04-12. Cani da guardia . Freedesktop.org.

— JdeBP
fonte

Naturalmente, devo risolvere il problema, la mia unica intenzione era quella di avere un trucco temporaneo fino a quando ho capito il problema. Grazie per la risposta dettagliata.

— freethinker