Prévenir l'admin si une erreur fatale survient

Bonjour,

Mon programme va tourner en permanence sur mon serveur et j'aimerais que si une erreur qui fait stoppé le programme survient je sois prévenu par un email. J'ai ma fonction mail() adéquate mais je ne sais pas comment l'enclencher en repérant une erreur fatale

Tu n'as pas utilisé d'api de loggage style log4j ? (parce que tu aurais tout ce qu'il faut pour faire cela).

Sinon, je ne sais ce que tu appelles une "erreur fatale" et comment tu la détécte dans le code. J'imagine que dans certains catch (qui seraient fatals) tu devrais appeler ta fonction mail....

Pour moi une erreur fatale est une erreur qui arrête le programme
C'est important pour moi de le savoir car ça veut dire qu'il faut vite que je retourne sur le serveur pour relancer le programme

J'ai du mal avec la phrase "une erreur qui arrête le programme".

Tu parles des éventuels et a priori exception non catchées, tel que les RuntimeException ?

Non toute les exceptions y compris les catchées qui arrêtent le programme
En fait dès que le programme est à l'arrêt il faut que je soit prévenu

Citation:

---

Envoyé par Ceubex

En fait dès que le programme est à l'arrêt il faut que je soit prévenu

---

Puis-je lire :

1) Dés que le programme est a l'arrêt. (donc il faut "un programme surveillant")

ou

2) Dés que le programme s'arrête. (donc il faut coder partout dans le programme ou il peut s'arrêter).

Parce que sinon ca va changer la donne.

Dès que le programme s'arrête
C'est pas compliqué, faut que le programme tourne sur mon serveur. Du coup s'il s'arrête, je suis prévenu, je vais le relancer et voilà. Faut que je puisse faire ça.

Bah il m'est arrivé d'avoir ce genre de problèmes.

Pour régler cela, je faisait un simple script bash qui

- Une boucle infinie

et dans la boucle

- Lancer le programme java (et attendre sa fin).
- Consulter un eventuel code de retour indiquant une terminaison normale (et donc sortir de la boucle eventuelement).
- Si le code est aps bon c'est que le programme s'est planté. Donc envoyer un mail avec un autre moyen.

Mais il est possible de faire un 2 ème programme java qui fera office de script bash.

Mais c'est une solution peut être pas des plus élégantes bien que ca a tjrs fonctionné dans mon cas... (mon but primaire etait d'avoir tjrs le programme java lancé car le serveur etait a petaouchnok ;), sans devoir etre prevenu mais bon c'est un details).

Ca evitera de toucher au programme existant (sauf pour le retour en cas de bonne terminaison retourné un code que le surveillant pourra identifier comme code de sortie correcte sinon c'est plantage).

Je ne suis pas persuadé qu'il faille passer par un second programme. La JRE gère le programme java. D'ailleurs quand un programme s'arrête, le JRE a encore le temps d'inscrire l'arborescence des causes dans la console. On doit pouvoir dire par l'intermediaire du JRE "si le programme s'arrête faire ceci"

Pourquoi ne le fais tu pas ainsi alors ? :p (je ne sais plus quoi proposer entres nous).

Je crois que je vais aller poser la question dans un endroit où on prend un peu moins de temps pour demander de décrire un problème simple et un peu plus pour réfléchir sur la solution

La solution de wax est la bonne et il a tout à fait raison de te poser toutes ces question. Ce n'est pas un problème "simple" que tu présente. Tu veux que ça marche à tous les coups? -> Tu dois passer par un programme extérieur. Pourquoi? Parce que tu as trois manière de sortir d'un programme java:

1) Quand le main a terminé et qu'il n'y a plus aucun thread non démon qui tourne. Si tu ne démarre pas d'autre thread (ce qui est rarement le cas sur un code en production), grosso-modo écrire

Code:

---

1 2 3 4 5 6 7

public static void main(String[] argv){ try { // ton code } finally { envoyerUnEmail(); } }

---

Si le main peux finir sans que le programme ne s'arrête, c'est inutilisable comme technique

2) Quand on appelle System.exit()/Runtime.exit()/Runtime.halt(). Là et dans les cas précédents non traités, il reste le Runtime.addShutdownHook(). Il est bien tentant mais il est clairement indiqué qu'il n'y a aucune garantie que les jvm les appelera et pour l'appel à halt(), aucun shutdownhook ne sera exécuté.... On tourne en rond

3) Quand la jvm crashe suite à un bug interne (et je t'assure que, occasionellement, en prod, ça arrive), ou quand on la kille violement (que ce soit un kill -9 ou le noyaux linux qui estime qu'elle consomme trop et présente un risque) -> Seul un programme externe pourra réagir et envoyer le mail.


D'ou la solution de wax. Maintenant, n'oublie pas, tu a traité un cas d'arrêt du service, il en reste d'autre comme: la jvm bouffe tous les CPU, ne répond plus mais ne crashe pas (ça c'est quand le GC essaie désespérement de retrouver un peu de mémoire), quand un bug de ton code fait qu'on ne sert plus, etc. Et là, seul un monitoring actif par un programme qui, par exemple, toutes les 5 minutes va demander à ton service de faire quelque chose, permettra de détecter ces arrêts de service.

Merci _Tchize pour l'apport, je pensais être devenu bête sinon ^^

Citation:

---

Envoyé par Ceubex

Je crois que je vais aller poser la question dans un endroit où on prend un peu moins de temps pour demander de décrire un problème simple et un peu plus pour réfléchir sur la solution

---

Le probleme est tellement simple que tu es obligé de poser une question sur un forum. Cela dit, tu as raison sur l'autre point. Il est inadmissible qu'apres 1h30 ou tu as posé la question sans aucun bout de code, personne n'ait trouvé la solution. Surtout que le probleme est bien posé : "une erreur qui fait stoppé le programme survient". C'est limpide.

Bref, au risque de me faire insulter, je vais quand meme essayer d'aider. Deja, il y a 2 types de verifications faisable. Soit tu estimes que si ton programme tourne, il fonctionne. Dans ce cas, une solution comme celle de wax est probablement le mieux (car comme précisé par tchize, le JRE peut aussi planter et j'imagine que dans ce cas, tu aimerais etre prévenu. C'est pas pour rien que les systemes de supervision sont généralement séparés des systemes de production).

Le 2e type de vérification est fonctionnel. Dans ce cas, l'idée serait que ton programme communique avec un autre et lui dise ce qu'il fait. Par exemple, toutes les 30 secondes, il donne le nombre de traitements qu'il a effectué. S'il ne dit rien ou qu'il donne de mauvaises info, alors il faudra le killer et le relancer/envoyer un mail. Ce mode est plus complexe mais est plus sur aussi. L'idéal étant bien sur que le 2e programme tourne sur une autre machine.
Ainsi, que le programme s'arrete sur une exception, un System.exit() ou bien qu'il soit tout simplement planté (par exemple boucle infinie), ca fonctionne. Mais c'est plus compliqué qu'un batch qui relance un executable...

Ou pour le dire autrement, la gestion des erreurs est une science en soi, et plein de gens seraient nettement moins bien payés si on pouvait juste oublier le problème après avoir posé une question sur un forum.

C'est la même chose que les gens qui demandent "j'ai fait un programme, maintenant je veux ajouter la sécurité."