Erreur bizarre

Le
Méta-MCI \(MVP\)
Bonjour !

J'ai un script, qui tourne sur un serveur, tous les 1/4 h.
Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois),
où il provoque cette erreur :

File "C:serv.py", line 69, in TCPersistEnvoiTxt
print "va envoyer"

IOerror: [Errno 9] Bad file descriptor

A chaque fois, le script étant relancé de zéro (tache planifiée), je ne
comprends pas pourquoi un simple print peut provoquer une erreur (en
plus, moins d'une fois sur mille).

Précisions :
Windows-2003-server, qui sert essentiellement en tant que serveur de
fichiers
Python 2.5.1
Même en cas d'erreur les lancements suivants du script fonctionnent
bien (la tache planifiée lance un nouveau processus à chaque fois).


Une idée ?


@+
--
Michel Claveau
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bruno Desthuilliers
Le #6334051
Bonjour !

J'ai un script, qui tourne sur un serveur, tous les 1/4 h.
Il fonctionne bien, sauf, de temps en temps (une ou deux fois par mois),
où il provoque cette erreur :

File "C:serv.py", line 69, in TCPersistEnvoiTxt
print "va envoyer"

IOerror: [Errno 9] Bad file descriptor

A chaque fois, le script étant relancé de zéro (tache planifiée), je ne
comprends pas pourquoi un simple print peut provoquer une erreur


print écrit sur le flux de sortie standard (ou, plus exactement, sur le
flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si
ce file descriptor est en vrac pour une raison ou une autre...

Accessoirement, sys.stdout est destiné à recevoir les sorties *normales*
d'un programme. Les erreurs, traces et autres devraient aller sur
sys.stderr.

(en
plus, moins d'une fois sur mille).

Précisions :
Windows-2003-server, qui sert essentiellement en tant que serveur de
fichiers
Python 2.5.1
Même en cas d'erreur les lancements suivants du script fonctionnent
bien (la tache planifiée lance un nouveau processus à chaque fois).


Une idée ?


Est-ce que par hasard la stdout du système serait redirigée vers un
fichier de log lors de l'appel du script ? Si oui, le pb doit être par là.

Sinon, attrape l'exception et logue (dans un fichier) un rapport sur
l'état de sys.stdout.

Désolé, pas mieux.

Amaury Forgeot d'Arc
Le #6371181
Bonjour !

J'ai un script, qui tourne sur un serveur, tous les 1/4 h.
Il fonctionne bien, sauf, de temps en temps (une ou deux fois par
mois), où il provoque cette erreur :

File "C:serv.py", line 69, in TCPersistEnvoiTxt
print "va envoyer"

IOerror: [Errno 9] Bad file descriptor

A chaque fois, le script étant relancé de zéro (tache planifiée), je
ne comprends pas pourquoi un simple print peut provoquer une erreur


print écrit sur le flux de sortie standard (ou, plus exactement, sur le
flux lié à sys.stdout, quel qu'il soit), qui est un file descriptor. Si
ce file descriptor est en vrac pour une raison ou une autre...

Accessoirement, sys.stdout est destiné à recevoir les sorties *normales*
d'un programme. Les erreurs, traces et autres devraient aller sur
sys.stderr.


Attention sous Windows, si tu utilises pythonw.exe ou des scripts en .pyw:

pythonw.exe n'est pas une application console, ses sys.sdtout et
sys.stderr ne sont connectés à rien.

Les premiers "print" se passent bien (même si on ne les voit pas).
Mais au bout de 1024 caractères, il doit y avoir un flush() interne, et
boum.

--
Amaury


Méta-MCI \(MVP\)
Le #6401421
Bonsoir !

L'hypothèse du buffer plein est une piste intéressante.
Car, en fait, le script s'exécute dans une console qui n'est pas la
console d'administration, et n'est donc pas affichée par défaut (en
pratique, je me connecte à distance en RDP).

Mais, si c'est ça, la taille avant que le buffer ne soit plein est
beaucoup plus grande que 1024 caractères (et puis, c'est sur un
serveur).
Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux...

@+

Michel Claveau
bruno.desthuilliers
Le #6401401
On 24 avr, 20:51, "Méta-MCI (MVP)" wrote:
Bonsoir !

L'hypothèse du buffer plein est une piste intéressante.
Car, en fait, le script s'exécute dans une console qui n'est pas la
console d'administration, et n'est donc pas affichée par défaut (en
pratique, je me connecte à distance en RDP).

Mais, si c'est ça, la taille avant que le buffer ne soit plein est
beaucoup plus grande que 1024 caractères (et puis, c'est sur un
serveur).
Je vais diminuer les "print", pour voir.


Une autre solution est de rediriger stdout sur un autre flux ouvert en
écriture (un fichier par exemple). Il suffit d'assigner ce flux à
sys.stdout, donc pas besoin d'aller toucher au reste du code.

MC
Le #6402711
'soir !

Une autre solution est de rediriger stdout sur un autre flux ouvert en
écriture (un fichier par exemple). Il suffit d'assigner ce flux à
sys.stdout, donc pas besoin d'aller toucher au reste du code.


Oui, à condition que sys.stdout ne tombe pas sur des contraintes
système similaire à la sortie standard.

Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet
d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.

Merci de m'avoir lu, et pour les suggestions.





--
@-salutations

Michel Claveau

Bruno Desthuilliers
Le #6403391
'soir !

Une autre solution est de rediriger stdout sur un autre flux ouvert en
écriture (un fichier par exemple). Il suffit d'assigner ce flux à
sys.stdout, donc pas besoin d'aller toucher au reste du code.


Oui, à condition que sys.stdout ne tombe pas sur des contraintes système
similaire à la sortie standard.


???

Tu veux dire "à condition que ce flux", je suppose (sinon ça n'a aucun
sens puisque sys.stdout *est* la sortie standard). Et je ne vois pas de
raisons pour qu'un fichier soit soumis à ce genre de contraintes.

Pour l'instant, J'ai réduit l'affichage à 2 caractères. Cela me permet
d'avoir toujours l'info, et de tester s'il y a une histoire de buffer.


Et si tu utilisais le module de log au lieu de la sortie standard, tout
simplement ?


Méta-MCI \(MVP\)
Le #6404621
Re !

Et si tu utilisais le module de log au lieu de la sortie standard,
tout simplement ?


Alors, log, ça irait pour cette installation ; mais les mêmes scripts
tournent sur plusieurs sites, dont certains pour lesquels print est
beaucoup plus facile à utiliser (serveurs sans clavier, par exemple).
Et, ça m'embêterait d'avoir plusieurs versions.

D'autant plus que ça contournerait le problème, sans expliquer son
origine ; alors que, en réduisant simplement le print, c'est comme un
outil de diagnostic.

Il faut quand même que je rappelle que, lorsqu'il y a l'erreur, cela ne
bloque pas le script (l'erreur est interceptée), et, même avec un script
bloqué, les suivants fonctionnent (car ils sont lancés par des taches
planifiées).

@+

MCI

Boris Borcic
Le #6405081
Méta-MCI (MVP) wrote:
Bonsoir !

L'hypothèse du buffer plein est une piste intéressante.
Car, en fait, le script s'exécute dans une console qui n'est pas la
console d'administration, et n'est donc pas affichée par défaut (e n
pratique, je me connecte à distance en RDP).

Mais, si c'est ça, la taille avant que le buffer ne soit plein est
beaucoup plus grande que 1024 caractères (et puis, c'est sur un serve ur).
Je vais diminuer les "print", pour voir. Réponse dans un mois ou deux ...

@+

Michel Claveau





Peut-être les modules win32trace / win32traceutil pourraient-ils là s ervir (qui
viennent avec les "windows python extensions" de Mark Hammond). Voilà l e
commentaire au début de win32traceutil.py (intégré à Pythonwin). HTH. BB

# This is a helper for the win32trace module

# If imported from a normal Python program, it sets up sys.stdout and sys .stderr
# so output goes to the collector.

# If run from the command line, it creates a collector loop.

# Eg:
# C:>start win32traceutil.py (or python.exe win32traceutil.py)
# will start a process with a (pretty much) blank screen.
#
# then, switch to a DOS prompt, and type:
# C:>python.exe
# Python 1.4 etc...
# >>> import win32traceutil
# Redirecting output to win32trace remote collector
# >>> print "Hello"
# >>>
# And the output will appear in the first collector process.

# Note - the client or the collector can be started first.
# There is a 64k buffer. If this gets full, it is reset, and new
# output appended from the start.

Bruno Desthuilliers
Le #6406771
Re !

Et si tu utilisais le module de log au lieu de la sortie standard,
tout simplement ?


Alors, log, ça irait pour cette installation ; mais les mêmes scripts
tournent sur plusieurs sites, dont certains pour lesquels print est
beaucoup plus facile à utiliser (serveurs sans clavier, par exemple).


Qu'est-ce que ça change ???

Et, ça m'embêterait d'avoir plusieurs versions.


Le module logger peut envoyer ses infos sur sys.st[dout|err].

D'autant plus que ça contournerait le problème,


Non. Encore une fois, print affiche sur sys.sdtout, qui est destiné à
recevoir les sorties *normales* d'un programme. les messages d'erreurs
et autres, ça va sur sys.stderr. Et le module logger sert très
précisément à gérer les traces et autres infos de fonctionnement avec
plus de détails qu'une écriture directe sur sys.stderr.

sans expliquer son
origine ;


Ca c'est un autre problème.


Publicité
Poster une réponse
Anonyme