Discussion :

[Cafebar Jadi]

Bonjour,
j'ai un petit programme installé sur un PC auquel il m'est difficile de me connecter (réseau bloquant) qui devrait tourner H24 mais qui plante aléatoirement (mais pas chez moi bien sûr...)
Le collègue qui l'utilise (à l'autre bout de la France évidemment) est fréquemment obligé de le relancer le matin en arrivant au taf, mais pas de message d'erreur...
J'ai ajouté un try pour voir si un rigolo s'amuserait pas à le fermer dans son dos ou si une exception se produit:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
except KeyboardInterrupt:
        logger.exception("Fermé par interruption clavier")
except Exception as e:
        logging.basicConfig(filename='crash.log')
        logging.exception("CRASH:", e)

mais rien ne sort sur le fichier de log et pas de création de fichier crash.log.
Du coup je me tournais vers la bibliothèque faulthandler mais je ne comprends pas comment ça marche
Voici le bout de code que j'utilise pour essais:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
import faulthandler
if __name__ == "__main__":
    with open("crash.log","w") as fichier:
        faulthandler.enable(file=fichier)
    while True:
        pass

Mais si je ferme la fenêtre (clic droit, fermer, OK pour "Do you want to kill?") , pas de message d'erreur dans crash.log
Qu'est-ce que j'ai raté?
Merci d'avance!

[wiztricks]

Salut,

Mais si je ferme la fenêtre (clic droit, fermer, OK pour "Do you want to kill?") , pas de message d'erreur dans crash.log

Un programme qui se termine via l'appel à exit() ne génère pas d'exception.

Normalement, pour savoir ce qu'il se passe, on ajoute des informations dans le log histoire d'avoir une idée de ce qui s'est passé un peu avant que le programme se termine.

Ça va donner des pistes qu'on essaie d'explorer pour voir où elles mènent. Et avec de la chance et un problème qui a le bon gout de se reproduire assez souvent on peut arriver à...

De toutes façons programmer une application qui tourne de façon fiable en H24 et qui donne des indications permettant un diagnostic en cas de plantage est un exercice très difficile (même pour des programmeurs expérimentés).

Je ne sais pas ce que votre programme fait mais si vous pouviez replacer le H24 par une tache lancée toutes les N secondes/minutes par un gestionnaire de tâche vous auriez déjà une solution plus robuste (et facile à coder).

- W

[Cafebar Jadi]

En théorie, fermer la fenêtre génère un "SIGTERM" ou équivalent (c'est sous Windows).
Si je fais CTRL+C c'est un SIGINT et là j’intercepte bien le KeyboardInterupt.
C'est donc les signaux SIGTERM (ou autre signal Windows ) que j'essaye de traiter, mais comment faire?

[wiztricks]

Salut,

En théorie, fermer la fenêtre génère un "SIGTERM" ou équivalent (c'est sous Windows).

Ce n'est pas parce que le résultat est identique (fin du programme) que le chemin est le même... ne serait ce que pour lui faire faire autre chose (reprogrammer ce qui se passe lorsque l'utilisateur ferme la fenêtre principale), vous ne passez pas par l'écriture d'un signal handler.

C'est donc les signaux SIGTERM (ou autre signal Windows ) que j'essaye de traiter, mais comment faire?

Si malgré tout, vous voulez suivre cette piste, il faut aller voir la bibliothèque python standard qui interface le "langage" avec les signaux.... voire trouver une bibliothèque externe plus robuste côté Windows.

- W

[Invité]

Bonjour, peut-être qu'en exécutant le message sur un terminal pourrais donner l'erreur.
chez moi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
giovanni@giovanni-System-Product-Name:~$ python3 /a.py
Traceback (most recent call last):
  File "/a.py", line 1, in <module>
    a
NameError: name 'a' is not defined

sous Windows ça donne ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Microsoft Windows [version 10.0.19043.985]
(c) Microsoft Corporation. Tous droits réservés.
 
C:\Users\gio26>python.exe c:/a.py
Traceback (most recent call last):
  File "c:/a.py", line 1, in <module>
    print(a)
NameError: name 'a' is not defined
 
C:\Users\gio26>

[Cafebar Jadi]

Bonjour,
après moult essais et lecture, le problème reste insoluble: il semblerait que lorsque Windows ferme une fenêtre il n'y ait pas moyen de lancer du code de sortie.
Donc il ne me reste plus qu'a demander à mon collègue de m'envoyer les events Windows pour essayer de comprendre.
Merci à tous ceux qui ont bien voulu essayer de m'aider!

[wiztricks]

Salut,

après moult essais et lecture, le problème reste insoluble: il semblerait que lorsque Windows ferme une fenêtre il n'y ait pas moyen de lancer du code de sortie.

Lorsque l'utilisateur demande la fermeture d'une fenêtre, il y a toujours la possibilité d'y accrocher un callback et c'est documenté. Lorsqu'un utilisateur arrête intempestivement une application via TerminateProcess (appel système Windows), les handlers de sortie de l'application ne seront pas toujours exécutés (et on ne pourra rien faire).

Maintenant, vous êtes en train de chercher à savoir pourquoi votre application s'arrête. Est ce que vous pensez sérieusement que c'est parce qu'un utilisateur a forcé son arrêt (avec TerminateProcess)? Si c'est le cas, vous allez en avoir la trace dans les journaux de sécurité (pour autant que la trace de ce genre d'évènement ait été activée).

- W

[Cafebar Jadi]

Lorsque l'utilisateur demande la fermeture d'une fenêtre, il y a toujours la possibilité d'y accrocher un callback

En Python ça a pas l'air évident... mais si vous pouvez me proposer du code qui le fait je suis preneur!

Est ce que vous pensez sérieusement que c'est parce qu'un utilisateur a forcé son arrêt (avec TerminateProcess)?

Quand on cherche et qu'on a pas de piste, tout est envisageable... même un farceur
Le bout de programme tourne sur un PC "ouvert à tous": il écoute un flux réseau local, décode et traite les informations, les affiche et les log dans un format souhaité par le collègue: n'importe qui (le gardien?) passant par là le soir et voyant la fenêtre ouverte pourrait faire n'importe quoi...
Et non, ce n'est pas à la rotation de log que ça plante, déjà vérifié...

[wiztricks]

Salut,

En Python ça a pas l'air évident... mais si vous pouvez me proposer du code qui le fait je suis preneur!

Déjà çà dépend du GUI avec lequel a été codé la fenêtre.
Si vous avez codé çà windows natif, je ne vois pas où est la difficulté puisque vous avez codé votre fenêtre avec.
Et si c'est un autre GUI, c'est aussi documenté et vous avez certainement des exemples de code.

Quand on cherche et qu'on a pas de piste, tout est envisageable... même un farceur
Le bout de programme tourne sur un PC "ouvert à tous": il écoute un flux réseau local, décode et traite les informations, les affiche et les log dans un format souhaité par le collègue: n'importe qui (le gardien?)

Coupez le problème en deux: une tache en background/daemon qui écoute et loggue et une tache utilisateur qui affiche les dernières mises à jours faites dans le log.
Si votre théorie est juste, seul la tache utilisateur sera arrêté mais le log continue de se remplir (et pourra être visualisé plus tard).

Autre stratégie, vous avez la fréquence des incidents. Faites tourner le programme sur un PC qui n'est pas ouvert à tous 2/3 fois plus longtemps (et en même temps) pour voir...

Vous avez aussi des programmes qui se terminent anormalement "sans erreur" utilisateur parce qu'un pilote accède à des données mémoires protégées. Mais çà devrait laisser une trace dans le journal d'évènements.

- W

[Cafebar Jadi]

Merci pour toutes ces pistes!
Le GUI est en TKinter, je n'avais pas pensé à regarder dedans, c’était pourtant évident...
Pour info, root.protocol("WM_DELETE_WINDOW", callback) est ce que je cherchais.
Et après consultation des events du poste, je verrai si nécessaire à réaliser un daemon
Merci encore @wiztricks