Vous avez passé tous les pièges de la programmation sous Windows et vous avez un service qui tourne. Bien. Ce sentiment de victoire ne dure jamais longtemps. Quelques minutes plus tard, ou quelques jours plus tard selon la verbosité de votre bébé, votre service va freezer. Et vous ne saurez pas pourquoi.
La raison de cette débandade, c’est que sous Windows les buffers de stdout et de stderr sont fixes. Si l’un des d’eux se devient plein, à la prochaine écriture, votre application va attendre le droit d’écrire pour une éternité ou deux.
Il existe plusieurs solutions:
- Garantir que votre application n’écrit jamais sur
stdout/stderr. - Utiliser systématiquement le module
logging(ce qui revient au point précédent). - Gérer manuellement le remplissage des buffers. Bon courage.
La solution la plus simple est de considérer que vos utilisateurs finaux n’en ont rien à secouer de la sortie de votre service, et de la rediriger sur l’équivalent Windows de /dev/null. En mode production (bah oui pas en dev, sinon débugguer devient encore plus chiant), ajoutez cela au début de votre code:
import sys sys.stdout = sys.stderr = open('nul', 'w') |
nul est un pseudo fichier présent dans tous les dossiers sous Windows dans lequel on peut écrire tout ce qu’on veut passer sous silence.
Ça ne vous dispense pas de faire un système de log des erreurs pour que les utilisateurs puissent rapporter des bugs, mais au moins vous avez l’esprit tranquile.
D’un certain coté, si c’est vraiment un service qui est développé, je vois mal où on peut lire la sortie en tout cas en fonctionnant en tant que service
En mode dev on peut lancer le service non daemonisé justement pour faciliter le debugging. C’est une pratique courrante pour éviter de se tapper des le début le setup de tout le system de log.
Quand le service devient complexe, on finit toujours par foutre du log partout vu qu’on arrive souvent à obtenir des bugs qui n’apparaissent qu’en mode daemon.
A noter que daemon est un abus de langage puisqu’il n’y a rien de tel dans le monde windows.