Ok. Donc, les watchdog, ça sert à rien, revenons à sysVinit (parce que oui, l'intérêt majeur de systemd (et d'autres) est bien de proposer un mécanisme de watchdog logiciel). Quand ça crash, on fait un déplacement (allez, 300 bornes, c'est rien...) et on fait un rapport de bug ou on patche, en espérant qu'il n'y ait plus de freeze.
En fait, même les containers, ça sert à rien: s'il y a une faille, on fait un rapport de bugs et/ou corriger le problème.
Wow tout doux. Sans même avoir à parler d'implémentation. Comment un système peut déterminer qu'une application doit avoir une interface graphique ou non ? Comment ce dernier peut interagir avec elle ? Et enfin pour lui dire quoi ?
Si tu veux ce genre de choses il faut :
mettre en place une description de ce qui semble être un comportement normal ou non de ton appli
mettre en place un protocole pour interagir avec ton appli1
Et le gain c'est éviter d'avoir à tuer toi-même un processus ? Et espérer qu'une application dont l'interface graphique est stuck ne sera pas tout aussi bloquée sur son autre interface ?
Perso, ma solution dans ces cas la, c'est d'essayer de revenir a du moins accéléré, moins performant, plus cher (en temps immédiat de dev) mais plus simple, plus maintenable et plus fiable (en gros, du KISS, qui a un réel coût).
Non de ce que tu décris tu as utilisé une solution ad-oc pour un besoin précis. Ce qui est très bien. Pousser cette rigueur pour tout le monde va être dramatiquement plus complexe :
il faut que la solution soit généralisation, qu'elle mette tout le monde d'accord3
il faut que ce soit implémenté dans les WM, par les bibliothèques graphiques et par les appli (gtk/qt ne peuvent pas deviner si c'est normal ou non de ne plus avoir de gui)
Tout ça pour une solution qui ne pourra pas gérer tout tes cas. Je ne vois pas ce qui pousserait une appli buguée à ne pas l'être sur une autre interface. Sachant qu'avec les signaux elle peut déjà faire pas mal de choses. Mais par contre tu complexifie encore ce qu'est une application graphique ce qui augmente les bugs potentiels.
C'est une solution de merde, clairement, mais pas trop eu le choix (compte tenu des impératifs de temps, le client était vraiment pas content d'avoir des trucs qui bugguent tout le temps, et le patron était pas fan non plus: il fallait du simple, qui juste marche).
Je n'en sais rien si c'est mal ou pas. Si ça fonctionne pourquoi ce serait si mal. Il semble que chez toi les navigateurs leaks des processus et ou ton pilote graphique/X11/les bibliothèques graphiques plantent en boucle ce n'est pas ce que j'observe. Je ne remet pas en cause ce que tu dis, mais ça ne me paraît pas la norme.
Mais quand j'ai besoin de fiabilité élevée, je met en place des solutions ad-oc et je sais qu'on ne peut pas la construire pour moi (ça ne remplirait probablement que partiellement mon besoin et tout le monde n'a pas à se plier à mes besoins).
Note: tout de même que quand je parle de remonter un bug (et en faire le suivi) ou un patch ce n'est pas une parole en l'air. Quelque soit le système c'est une étape de dernier recours. Ça ne doit pas arriver. Ce n'est pas parce que j'ai un extincteur que je m'en fou de mettre le feu.
il me semble que gnome (et peut être KDE) définissent des usages de dbus pour interagir, ils pourraient faire des choses dans ton sens éventuellement (mais ça a beaucoup de mal à passer hors de leurs appli dédié) ↩
gnome met en place des usages de dbus (et je présume que d'autres aussi) mais là il faut se mettre d'accord au sein de freedesktop, mais quand tu vois comment les évolutions de wayland et de systemd (qui a son propre système de watchdog)rament pour être accepté et utilisé, je doute que le monde des appli avec interface graphiques y passent facilement ↩
[^] # Re: Mieux vaut des (processus) orphelins morts que des fils morts?
Posté par barmic 🦦 . En réponse à la dépêche Xfce 4.16 : La souris fait la fête !. Évalué à 2.
Wow tout doux. Sans même avoir à parler d'implémentation. Comment un système peut déterminer qu'une application doit avoir une interface graphique ou non ? Comment ce dernier peut interagir avec elle ? Et enfin pour lui dire quoi ?
Si tu veux ce genre de choses il faut :
Et le gain c'est éviter d'avoir à tuer toi-même un processus ? Et espérer qu'une application dont l'interface graphique est stuck ne sera pas tout aussi bloquée sur son autre interface ?
Non de ce que tu décris tu as utilisé une solution ad-oc pour un besoin précis. Ce qui est très bien. Pousser cette rigueur pour tout le monde va être dramatiquement plus complexe :
Tout ça pour une solution qui ne pourra pas gérer tout tes cas. Je ne vois pas ce qui pousserait une appli buguée à ne pas l'être sur une autre interface. Sachant qu'avec les signaux elle peut déjà faire pas mal de choses. Mais par contre tu complexifie encore ce qu'est une application graphique ce qui augmente les bugs potentiels.
Je n'en sais rien si c'est mal ou pas. Si ça fonctionne pourquoi ce serait si mal. Il semble que chez toi les navigateurs leaks des processus et ou ton pilote graphique/X11/les bibliothèques graphiques plantent en boucle ce n'est pas ce que j'observe. Je ne remet pas en cause ce que tu dis, mais ça ne me paraît pas la norme.
Mais quand j'ai besoin de fiabilité élevée, je met en place des solutions ad-oc et je sais qu'on ne peut pas la construire pour moi (ça ne remplirait probablement que partiellement mon besoin et tout le monde n'a pas à se plier à mes besoins).
Note: tout de même que quand je parle de remonter un bug (et en faire le suivi) ou un patch ce n'est pas une parole en l'air. Quelque soit le système c'est une étape de dernier recours. Ça ne doit pas arriver. Ce n'est pas parce que j'ai un extincteur que je m'en fou de mettre le feu.
on pourrait appeler ça dbus par exemple ↩
il me semble que gnome (et peut être KDE) définissent des usages de dbus pour interagir, ils pourraient faire des choses dans ton sens éventuellement (mais ça a beaucoup de mal à passer hors de leurs appli dédié) ↩
gnome met en place des usages de dbus (et je présume que d'autres aussi) mais là il faut se mettre d'accord au sein de freedesktop, mais quand tu vois comment les évolutions de wayland et de systemd (qui a son propre système de watchdog)rament pour être accepté et utilisé, je doute que le monde des appli avec interface graphiques y passent facilement ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll