Systemd peut-il détecter et tuer les processus bloqués?

En travaillant sur une solution qui utilise le verrouillage de fichiers, je pense que mon code se retrouve dans une impasse. J'utilise systemd pour lancer le processus au démarrage du système. L'utilisation de l'alarme (3) est une option, mais je me demandais s'il y avait un moyen pour systemd de détecter les processus bloqués et de les redémarrer?

Actuellement, pour contourner ce problème pour l'instant, je prévois d'examiner la sortie de journalctl et si elle ne change pas pendant une durée spécifiée, je tuerais le processus via un script shell.

Je me demande simplement s'il existe une meilleure façon de surveiller les processus via systemd ou autrement.

monitoring systemd

— libre penseur
source

Probablement pas. Comment savoir si le processus est suspendu? Et si vous avez vraiment besoin de quelque chose for(;;) do_something();?

— mvp

À strictement parler, si votre code se bloque, vous devez déboguer ce problème. Le tuer via systemd (en supposant que cela puisse être fait, ce que je ne crois pas) ou de toute autre manière est la chose à faire lorsque vous le déboguez. Mais vous ne pouvez tout simplement pas le laisser libre d'entrer dans une impasse.

— MariusMatutiae

Oui; mais corrigez d'abord votre programme de buggy avant de jouer avec systemd.

MariusMatutiae est tout à fait correct. Vous avez un problème avec votre programme. Il se bloque. Jouer avec systemd n'est pas la réponse. Au mieux, c'est une distraction. Réparez votre programme afin qu'il ne soit pas endommagé. Dirigez vos énergies vers la bonne chose.

Cela dit, d'autres personnes vont venir ici à cause du titre de la question plutôt que de la question proprement dite. Pour leur bénéfice, voici la réponse au titre, en ignorant la question proprement dite:

Oui, systemd peut surveiller les démons et les redémarrer automatiquement s'ils arrêtent de parler. Mais pas n'importe quel vieux démon. Comme le note mvp, il n'y a aucun moyen de savoir qu'un démon s'est bloqué (dans cet univers, où le problème d'arrêt est indécidable, au moins). Ni systemd ni aucun autre programme informatique ne seront jamais capables de déduire de zéro qu'un programme aléatoire lancé sur eux est bloqué, ou est entré dans une boucle infinie, ou autre chose. Le mieux que vous obtiendrez ici est de détecter qu'un démon n'a pas effectué une opération régulière de «battement de cœur» dans un délai requis.

Les Dæmons qui profitent des capacités de surveillance de systemd doivent donc être écrits pour parler un protocole spécifique à systemd, le protocole sd_notify. Cela complique un peu le code démon. C'est encore plus compliqué car les dæmons devraient, s'ils sont écrits correctement, vérifier s'ils ont également été invoqués avec la fonction de surveillance activée.

Un démon qui parle de ce protocole pour utiliser la capacité de surveillance de systemd…

… Doit vérifier la WATCHDOG_USECvariable d'environnement;
… Doit appeler sd_notify () continuellement et fréquemment, tout au long de sa durée de vie, avec l' WATCHDOG=1option définie, à un intervalle d'environ WATCHDOG_USEC/ 2 («USEC» signifie microsecondes);
… Doit avoir Type=notifyplacé dans son fichier d'unité;
… Devrait avoir NotifyAccess=main(ou =all) défini dans son fichier unité;
… Doit avoir des WatchdogSec=secondes définies dans son fichier d'unité.
… Doit être lié à libsystemd-daemon.so

Si vous voulez connaître les détails du codage, après avoir lu le manuel, assurez-vous d'aller au bon StackExchange. C'est SuperUser. StackOverflow est là-bas .

Lectures complémentaires

Lennart Poettering. 2011-04-12. Chiens de garde . Freedesktop.org.

— JdeBP
source

Bien sûr, je dois résoudre le problème, ma seule intention était d'avoir un hack temporaire jusqu'à ce que je trouve le problème. Merci pour la réponse détaillée.

— Libre