This looks 'interesting' :
Kill process group (anything launched by PID 21107)
Kill process group 18226 (anything launched by PID 21107) [from 21109]
for:
pgrpID=os.getpgid(pid)
log.warn('Kill process group %s (anything launched by PID %s) [from
%s]' \
% (pgrpID, pid, os.getpid()))
It is unlikely that 21109 is the 'parent' of 21107. (Even Brutus isn't that
busy :-) Hmm, maybe it is that the timer is running in a sub-process (some
Python impl detail?), and the main process was 18226. That might be
possible, seeing as the lock file contains 18231.
Mind you, this leads to ...
Looking at the code, I see no 'setpgid', which is disturbing (to say the
least). The logic of this kill means the forked child needs to place itself
into it's own process group. Without that, the parent (main Gump) is likely
a equal target for termination. I (now) suspect that is the problem. I
certainly makes sense w/ the output we see.
[BTW: Somehow when I ported from the test script, python/misc/pgrp.py I lost
this 'minor' detail. Hopefully with Gump3 we all have better luck w/
repeatably unit testing "integration" code.]
regards
Adam
----- Original Message -----
From: "Davanum Srinivas" <[EMAIL PROTECTED]>
To: "Adam R. B. Jack" <[EMAIL PROTECTED]>
Cc: "Gump code and data" <general@gump.apache.org>
Sent: Tuesday, April 26, 2005 1:56 PM
Subject: Re: Has the Kaffe Gump run died?
no luck :( kaffe run still dies.
-- dims
On 4/26/05, Adam R. B. Jack <[EMAIL PROTECTED]> wrote:
> > oops...i already merged your patch to live :(
>
> I doubt they are harmful, I just wasn't 100% certain they were sure fixes.
>
> regards
>
> Adam
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
