[ZCM] [ZC] 1588/ 9 Resolve "testSubprocessBasic fails on Mac OS X"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #1588 Update (Resolve) "testSubprocessBasic fails on Mac OS X"
 Status Resolved, Zope/bug medium
To followup, visit:
  http://www.zope.org/Collectors/Zope/1588

==============================================================
= Resolve - Entry #9 by efge on May 18, 2005 2:16 pm

 Status: Pending => Resolved

It's not an issue anymore, at least on Mac OS X 10.4.1 with stock python 2.3.5.
I'll assume it was fixed by something in Zope.

________________________________________
= Comment - Entry #8 by ajung on May 18, 2005 11:37 am

Is this still an issue? I haven't had any problems with running the 
unittests on my Powerbook with the trunk lately?!
________________________________________
= Comment - Entry #7 by efge on Nov 22, 2004 11:57 am

Please disregard entry #5, it's not the same (it's actually the same as the Zope 3 one).

Even though they all probably have a common cause, fucked up signal handling.

________________________________________
= Comment - Entry #6 by efge on Nov 22, 2004 11:54 am

The Zope 3 bug http://zope.org/Collectors/Zope3-dev/318 is probably related.

________________________________________
= Comment - Entry #5 by efge on Nov 22, 2004 11:52 am

http://zope.org/Collectors/Zope/1361 is a duplicate of this bug, but on Linux.

________________________________________
= Comment - Entry #4 by jens on Nov 22, 2004 4:08 am

There seem to be quite a few strange signaling-related problems on OS X and since they just don't happen on Linux I've been blaming OS X for misbehaving. Here is a couple I have run into:

- Run a Zope or ZEO client in the foreground for debugging. Under normal circumstances hitting CTRL-C works fine for ending the process. However, after going through a pdb.set_trace in the foregrounded process it does not work anymore, even if I have long left the set_trace. Only solution: Put it in the background with CTRL-Z and then force-kill the backgrounded process with kill -9 % 

- Run a ZEO server and client on your OS X box and set them to communicate via a Unix socket file (this symptom does not affect those who use network sockets). Foreground the ZEO client, e.g. by running zopectl fg. When using CTRL-C on the foregrounded client to stop it all of a sudden the ZEO server will shut down as well.

________________________________________
= Comment - Entry #3 by efge on Nov 21, 2004 6:49 pm

If I comment out the
  signal.signal(signal.SIGCHLD, signal.SIG_IGN)
in zopectl.py, the test now passes.

I've tried instead just adding a
  signal.signal(signal.SIGCHLD, signal.SIG_DFL)
inside the test, but it's not enough. On this platform, and maybe other BSDs, there's a weird behavior related to SA_NOCLDWAIT and its inheritence at fork time; I can't seem to understand exactly what's happening.

This thread about Perl is interesting: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-06/msg00364.html

________________________________________
= Comment - Entry #2 by efge on Nov 21, 2004 5:32 pm

Ok if I run it directly using

  python test.py -vv --config-file etc/zope.conf --libdir lib/python --dir lib/python/zdaemon testzdrun testSubprocessBasic

then it works, so the culprit must be in zopectl...

________________________________________
= Request - Entry #1 by efge on Nov 21, 2004 5:09 pm

On Mac OS X (10.3.6) testSubprocessBasic fails. It passes on Linux:

 bin/zopectl test -vv --libdir lib/python --dir lib/python/zdaemon testzdrun testSubprocessBasic
 [...]
 ERROR: testSubprocessBasic (zdaemon.tests.testzdrun.ZDaemonTests)
 Traceback (most recent call last):
   File "/Users/fg/zope/zopehead/lib/python/zdaemon/tests/testzdrun.py", line 171, in testSubprocessBasic
     wpid, wsts = os.waitpid(pid, 0)
 OSError: [Errno 10] No child processes

It looks like waitpid returns an error because there is no process to wait for. A kernel trace gives:

  [...]
  5051 sleep    CALL  sigaction(0xe,0xbffff900,0xbffff970)
  5051 sleep    RET   sigaction 0
  5050 python   RET   select 0
  5050 python   CALL  kill(0x13bb,0xf)
  5050 python   RET   kill 0
  5050 python   CALL  wait4(0x13bb,0xbfffce68,0,0)
  5051 sleep    PSIG  SIGTERM SIG_DFL
  5050 python   RET   wait4 -1 errno 10 No child processes

I don't understand why Mac OS X behaves this way. I'll try to reduce to a simple testcase.

==============================================================