RE: python.exe vs pythonw.exe difference?
[moving this from comp.lang.python to zope-dev; it really belongs on a Zope list, although schemes to change what pythonw does probably belong on python-dev] [Emile van Sebille <emile@fenx.com>]
I've possibly narrowed a problem I'm having running zope as a service on winxp pro sp 1 in that when started from a command line as:
c:\zope\v27\lib\python\python.exe \ c:\zope\v27\lib\python\zope\startup\run.py -C \ c:\zope\v27\instance\etc\zope.conf
[tim inserted backslashes above, to make the line structure clear]
it starts up just fine (although now running from the console).
But when I start it with:
c:\zope\v27\lib\python\pythonw.exe \ c:\zope\v27\lib\python\zope\startup\run.py -C \ c:\zope\v27\instance\etc\zope.conf
it dies after about 30 seconds.
It wouldn't surprise me that I'm doing something it doesn't like (I'm spawning additional processes from within a product but it worked fine with 2.5),
It's unclear what "it" means, in "it wworked fine with 2.5". For example, do you mean that the second command line, using pythonw.exe explicitly from a DOS box worked fine, or do you mean that running Zope as a service on XP Pro SP1 worked fine, or ...?
but I'm somewhat at a loss as to debugging it in> that when run as a console app it works fine, but when run windowless it doesn't.
Did you look in your Zope log file(s) for tracebacks?
Do I have to write out check points to a file? or is there some way to use Mark Hammonds process debugging tools? Or is this a bug, known or otherwise?
[Thomas Heller]
It has been reported that writing to the original sys.stdout (and maybe also sys.stderr) sooner or later raises an IOError when running pythonw.exe, unless these are redirected. Could this be the problem?
It could, although I have no idea what WinXP does (and don't have access to XP). Here's a Python program to try: """ import sys if 1: # edit to 1 for stdout, 0 for stderr console = sys.stdout else: console = sys.stderr import traceback tb = file('tb.txt', 'w') try: i = 0 while True: i += 1 console.write('.') except: print >> tb, "Died when trying to write byte", i traceback.print_exc(file=tb) tb.close() """ Under Win98SE, and regardless of whether it writes to stdout or stderr, it dies when run under pythonw, and tb.txt contains this after: Died when trying to write byte 4097 Traceback (most recent call last): File "wr.py", line 14, in ? console.write('.') IOError: [Errno 9] Bad file descriptor The point of pythonw.exe is that no console is created or inherited, and the default stdin, stdout and stderr provided by MS C in that case are unusable (although the output flavors can appear to be usable until some secret MS limit is exceeded -- at least under Win98SE).
"Tim Peters" <tim@zope.com> writes:
[moving this from comp.lang.python to zope-dev; it really belongs on a Zope list, although schemes to change what pythonw does probably belong on python-dev]
[I'm currently reading python-list via the gmane nntp interface, I don't know whether there really is a gmane.comp.web.zope.devel newsgroup]
[Thomas Heller]
It has been reported that writing to the original sys.stdout (and maybe also sys.stderr) sooner or later raises an IOError when running pythonw.exe, unless these are redirected. Could this be the problem?
It could, although I have no idea what WinXP does (and don't have access to XP). Here's a Python program to try:
""" import sys if 1: # edit to 1 for stdout, 0 for stderr console = sys.stdout else: console = sys.stderr
import traceback tb = file('tb.txt', 'w')
try: i = 0 while True: i += 1 console.write('.') except: print >> tb, "Died when trying to write byte", i traceback.print_exc(file=tb) tb.close() """
Under Win98SE, and regardless of whether it writes to stdout or stderr, it dies when run under pythonw, and tb.txt contains this after:
Died when trying to write byte 4097 Traceback (most recent call last): File "wr.py", line 14, in ? console.write('.') IOError: [Errno 9] Bad file descriptor
I get exactly the same, on Win XP Pro, both for sys.stdout and sys.stderr.
The point of pythonw.exe is that no console is created or inherited, and the default stdin, stdout and stderr provided by MS C in that case are unusable (although the output flavors can appear to be usable until some secret MS limit is exceeded -- at least under Win98SE).
Since it seems XP shows the same behaviour than win98SE, has the behaviour of Python changed? Were IOErrors ignored on sys.stdout or sys.stderr in earlier versions? IIRC, /F first proposed that pythonw.exe should create a console to have a place to show tracebacks. Sounds like a good idea to me. Thomas
Thomas Heller wrote:
"Tim Peters" <tim@zope.com> writes:
[moving this from comp.lang.python to zope-dev; it really belongs on a Zope list, although schemes to change what pythonw does probably belong on python-dev]
[I'm currently reading python-list via the gmane nntp interface, I don't know whether there really is a gmane.comp.web.zope.devel newsgroup]
Heh, yep. That is where I saw yours. Tres. -- =============================================================== Tres Seaver tseaver@zope.com Zope Corporation "Zope Dealers" http://www.zope.com
[Thomas Heller]
[I'm currently reading python-list via the gmane nntp interface, I don't know whether there really is a gmane.comp.web.zope.devel newsgroup]
I don't know either, so I'll copy you directly. [Tim]
... Here's a Python program to try:
""" import sys if 1: # edit to 1 for stdout, 0 for stderr console = sys.stdout else: console = sys.stderr
import traceback tb = file('tb.txt', 'w')
try: i = 0 while True: i += 1 console.write('.') except: print >> tb, "Died when trying to write byte", i traceback.print_exc(file=tb) tb.close() """
Under Win98SE, and regardless of whether it writes to stdout or stderr, it dies when run under pythonw, and tb.txt contains this after:
Died when trying to write byte 4097 Traceback (most recent call last): File "wr.py", line 14, in ? console.write('.') IOError: [Errno 9] Bad file descriptor
[Thomas]
I get exactly the same, on Win XP Pro, both for sys.stdout and sys.stderr.
That's good to know! Thanks.
... Since it seems XP shows the same behaviour than win98SE, has the behaviour of Python changed? Were IOErrors ignored on sys.stdout or sys.stderr in earlier versions?
No, the same program fails the same way here under pythonw 2.2.3 and 2.1.3 (with s/file/open/ and s/True/1/). The OP wasn't clear about what "it" meant, though (in "it used to work"). I guess it's most likely he meant running Zope 2.5 as a service used to work, not that running Zope 2.5 by hand from a DOS box with pythonw used to work, but don't know. It's certainly possible that something relevant changed in Zope, and/or in how Zope tries to live with Windows services.
IIRC, /F first proposed that pythonw.exe should create a console to have a place to show tracebacks. Sounds like a good idea to me.
Some way of having pythonw not drop output into the bit bucket has sounded like a good idea to everyone for about a decade now <wink>. ideas-ain't-code-ly y'rs - tim
Tim:
[Thomas]
I get exactly the same, on Win XP Pro, both for sys.stdout and sys.stderr.
That's good to know! Thanks.
... Since it seems XP shows the same behaviour than win98SE, has the behaviour of Python changed? Were IOErrors ignored on sys.stdout or sys.stderr in earlier versions?
No, the same program fails the same way here under pythonw 2.2.3 and 2.1.3 (with s/file/open/ and s/True/1/). The OP wasn't clear about what "it" meant, though (in "it used to work"). I guess it's most likely he meant running Zope 2.5 as a service used to work, not that running Zope 2.5 by hand from a DOS box with pythonw used to work, but don't know. It's certainly possible that something relevant changed in Zope, and/or in how Zope tries to live with Windows services.
To clarify, at that site I'm migrating from zope2.5/python2.1/win2k box to zope2.7/python2.3/winxppro. When "it used to work" I was referring to my product running within zope as a service. For initial debugging in the new environment, I started in console mode. Once things stabilized, I started the service up and the problem surfaced. Backtracking through the code I found the service starting the application as per my earlier post with pythonw.exe which led me to the direct comparison. It did look like there'd been some significant refactoring going on within zope and windows service interaction, but replicating the effect directly using pythonw vs python seems to take that out of the picture. (hence the post to the python list and not the zope list. I really should remember that python-dev is an open list now...) At this point, I won't be back to that site before next week, although I may take some time to test this weekend. It sounds like I should rework any areas that spew output to the console. Is there something better than checking os.path.basename(sys.executable)?
ideas-ain't-code-ly y'rs - tim
That'd be too easy! Just ask that other Tim... Emile van Sebille emile at fenx dot com emile@fenx.com
[Emile van Sebille]
... At this point, I won't be back to that site before next week, although I may take some time to test this weekend. It sounds like I should rework any areas that spew output to the console. Is there something better than checking os.path.basename(sys.executable)?
You could use the logging module all the time instead of trying to make the destination conditional on the executable name. Bad errors should probably be reported to the Windows Event Log service too; doing a serious job of making a thing a Windows Service is painful.
participants (5)
-
Emile van Sebille -
Thomas Heller -
Tim Peters -
Tim Peters -
Tres Seaver