You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/01/12 10:47:38 UTC
Killed a bunch of undead Kaffe processes
Just as a heads-up.
I don't think there is a Kaffe build currently on the way, but my kill
-9 may be responsible for a single build failure if I'm wrong. The
total number of kaffe-bin processes has been somewhere in the 20s.
The machine went down from a load average > 7 to about 2 after I
killed some processes who had collected more than thousand CPU
minutes. At the same time Kaffe has let go of some TCP ports that the
commons-net tests use.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Kaffe fails to kill subprocesses (was Re: Killed a bunch of undead Kaffe processes)
Posted by Davanum Srinivas <da...@gmail.com>.
Did you guys see
http://www.haystack.mit.edu/cgi-bin/millstone_viewcvs.cgi/prototypes/Modules/ProcessGroup/?
I don't mind a solution that does "ps -ef" and follows that with a
"os.kill" AND
kill -9" as is being done here in the code (at least we should use
that on Unix'es.)
-- dims
On Thu, 13 Jan 2005 12:27:18 +0100, Leo Simons <ma...@leosimons.com> wrote:
> If we implement a global lock to prevent concurrent builds we can do some
> "grep" and "killall" to automate the stuff we do manually every now and
> then. I dunno. I concur that doing this in python tends to suck.
>
> - LSD
>
>
> On 12-01-2005 20:05, "Adam R. B. Jack" <aj...@apache.org> wrote:
> > I believe this is a Python Gump message. I've fought (and fought, and
> > re-written, and fought) Python here. Trying to get a portable/workable 'kill
> > off spawn' has failed. I've read documentation, I've read cookbooks, nothing
> > seems to give what we need -- i.e. kill off grandchild processes.
> >
> > All inputs welcomed.
> >
> > regards
> >
> > Adam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Kaffe fails to kill subprocesses (was Re: Killed a bunch of
undead Kaffe processes)
Posted by Leo Simons <ma...@leosimons.com>.
If we implement a global lock to prevent concurrent builds we can do some
"grep" and "killall" to automate the stuff we do manually every now and
then. I dunno. I concur that doing this in python tends to suck.
- LSD
On 12-01-2005 20:05, "Adam R. B. Jack" <aj...@apache.org> wrote:
> I believe this is a Python Gump message. I've fought (and fought, and
> re-written, and fought) Python here. Trying to get a portable/workable 'kill
> off spawn' has failed. I've read documentation, I've read cookbooks, nothing
> seems to give what we need -- i.e. kill off grandchild processes.
>
> All inputs welcomed.
>
> regards
>
> Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Kaffe fails to kill subprocesses (was Re: Killed a bunch of undead Kaffe processes)
Posted by "Adam R. B. Jack" <aj...@apache.org>.
I believe this is a Python Gump message. I've fought (and fought, and
re-written, and fought) Python here. Trying to get a portable/workable 'kill
off spawn' has failed. I've read documentation, I've read cookbooks, nothing
seems to give what we need -- i.e. kill off grandchild processes.
All inputs welcomed.
regards
Adam
----- Original Message -----
From: "Stefan Bodewig" <bo...@apache.org>
To: <ge...@gump.apache.org>
Cc: "Steve Cohen" <sc...@javactivity.org>
Sent: Wednesday, January 12, 2005 6:51 AM
Subject: Kaffe fails to kill subprocesses (was Re: Killed a bunch of undead
Kaffe processes)
> Hi,
>
> during the current Kaffe run, commons-net's unit tests timed out and
> the builds ends with
>
> > Kill all child processed (anything launched by PID21010)
>
> unfortunately it doesn't. During the tests, commons-net starts some
> server processes that bind to TCP ports and those ports are still in
> state LISTEN (and lsof list kaffe-bin as owner).
>
> So far this has caused the commons-net builds on Sun VMs to fail as
> well, since they assumed the ports would be free. Steve Cohen hopes
> he's patched the tests to work around the problem. Let's keep our
> fingers crossed.
>
> Anyway, when Kaffe tries to kill the spawned subprocesses, it
> sometimes fails. Maybe this happens because the processes are
> grandchildren of the PID listed in the message.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Kaffe fails to kill subprocesses (was Re: Killed a bunch of undead
Kaffe processes)
Posted by Stefan Bodewig <bo...@apache.org>.
Hi,
during the current Kaffe run, commons-net's unit tests timed out and
the builds ends with
> Kill all child processed (anything launched by PID21010)
unfortunately it doesn't. During the tests, commons-net starts some
server processes that bind to TCP ports and those ports are still in
state LISTEN (and lsof list kaffe-bin as owner).
So far this has caused the commons-net builds on Sun VMs to fail as
well, since they assumed the ports would be free. Steve Cohen hopes
he's patched the tests to work around the problem. Let's keep our
fingers crossed.
Anyway, when Kaffe tries to kill the spawned subprocesses, it
sometimes fails. Maybe this happens because the processes are
grandchildren of the PID listed in the message.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org