Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Brandon Allbery
On Wed, Dec 7, 2011 at 20:35, Jason Dagit  wrote:

> > They *do* terminate; a zombie is a dead process waiting for its parent to
> > reap it with waitForProcess.  There's also some POSIX stuff you can do to
> > have them auto-reaped, but doing that correctly and portably is somewhat
> > painful.
>
> You can use a double fork to make this portable and not painful.  It's
> just that you have to fork twice, which can be expensive in some
> cases.
>

And problematic if you're using a pipe to communicate with the child, which
seemed quite possible.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Jason Dagit
On Wed, Dec 7, 2011 at 7:19 AM, Brandon Allbery  wrote:
> On Wed, Dec 7, 2011 at 06:47, Dan Rosén  wrote:
>>
>> I'm using Haskell to run a lot of instances of an Automated Thorem Prover,
>> eprover. I have pasted a smaller version of my program at
>> http://hpaste.org/54954. It runs eprover sequentially on all input files,
>> with a timeout of 100ms. Unfortunately, it leaves a lot of zombie processes
>> around, probably due to the fact that terminateProcess fails to terminate
>> them, even though eprover terminates on SIGTERM.
>
>
> They *do* terminate; a zombie is a dead process waiting for its parent to
> reap it with waitForProcess.  There's also some POSIX stuff you can do to
> have them auto-reaped, but doing that correctly and portably is somewhat
> painful.

You can use a double fork to make this portable and not painful.  It's
just that you have to fork twice, which can be expensive in some
cases.

Explanation here: http://stackoverflow.com/a/881434/5113

Here is a Haskell example from xmonad:
http://hackage.haskell.org/packages/archive/xmonad/0.7/doc/html/src/XMonad-Core.html#doubleFork

If you're planning to send a SIGTERM later, then double forking may
make that harder as I think you'd have to communicate the PID up one
level.

I hope that helps,
Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Dan Rosén
Thank you very much for your answers.

Felipe's suggestion to use waitForProcess after terminateProcess did the
trick. No more zombies around :)

Best regards,
Dan Rosén

On Wed, Dec 7, 2011 at 4:39 PM, Donn Cave  wrote:

> Quoth Felipe Almeida Lessa ,
> > On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery 
> wrote:
> >> They *do* terminate; a zombie is a dead process waiting for its parent
> to
> >> reap it with waitForProcess.  There's also some POSIX stuff you can do
> to
> >> have them auto-reaped, but doing that correctly and portably is somewhat
> >> painful.
> >
> > But zombie processes do consume a row in the process table, right?  If
> > so, then it's bad to have them around.
>
> Correct.  As noted above, clean up with waitForProcess to release this
> resource.  If it's more convenient, that could be done up front, by
> forking twice and waiting for the intermediate process.  One possibly
> convenient way to do that might be something like runCommand "eprover &".
>
>Donn
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Donn Cave
Quoth Felipe Almeida Lessa ,
> On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery  wrote:
>> They *do* terminate; a zombie is a dead process waiting for its parent to
>> reap it with waitForProcess.  There's also some POSIX stuff you can do to
>> have them auto-reaped, but doing that correctly and portably is somewhat
>> painful.
>
> But zombie processes do consume a row in the process table, right?  If
> so, then it's bad to have them around.

Correct.  As noted above, clean up with waitForProcess to release this
resource.  If it's more convenient, that could be done up front, by
forking twice and waiting for the intermediate process.  One possibly
convenient way to do that might be something like runCommand "eprover &".

Donn

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Brandon Allbery
On Wed, Dec 7, 2011 at 10:27, Felipe Almeida Lessa
wrote:

> On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery 
> wrote:
> > They *do* terminate; a zombie is a dead process waiting for its parent to
> > reap it with waitForProcess.  There's also some POSIX stuff you can do to
> > have them auto-reaped, but doing that correctly and portably is somewhat
> > painful.
>
> But zombie processes do consume a row in the process table, right?  If
> so, then it's bad to have them around.


Yes, and they count against the per-uid process limit.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Felipe Almeida Lessa
On Wed, Dec 7, 2011 at 1:19 PM, Brandon Allbery  wrote:
> They *do* terminate; a zombie is a dead process waiting for its parent to
> reap it with waitForProcess.  There's also some POSIX stuff you can do to
> have them auto-reaped, but doing that correctly and portably is somewhat
> painful.

But zombie processes do consume a row in the process table, right?  If
so, then it's bad to have them around.

-- 
Felipe.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Brandon Allbery
On Wed, Dec 7, 2011 at 06:47, Dan Rosén  wrote:

> I'm using Haskell to run a lot of instances of an Automated Thorem Prover,
> eprover. I have pasted a smaller version of my program at
> http://hpaste.org/54954. It runs eprover sequentially on all input files,
> with a timeout of 100ms. Unfortunately, it leaves a lot of zombie processes
> around, probably due to the fact that terminateProcess fails to terminate
> them, even though eprover terminates on SIGTERM.
>

They *do* terminate; a zombie is a dead process waiting for its parent to
reap it with waitForProcess.  There's also some POSIX stuff you can do to
have them auto-reaped, but doing that correctly and portably is somewhat
painful.

-- 
brandon s allbery  allber...@gmail.com
wandering unix systems administrator (available) (412) 475-9364 vm/sms
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


Re: [Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Felipe Almeida Lessa
Quick suggestion:  did you try using waitForProcess just after terminateProcess?

Cheers,

-- 
Felipe.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe


[Haskell-cafe] terminateProcess leaves zombie processes around

2011-12-07 Thread Dan Rosén
Hi Haskell-Cafe,

I'm using Haskell to run a lot of instances of an Automated Thorem Prover,
eprover. I have pasted a smaller version of my program at
http://hpaste.org/54954. It runs eprover sequentially on all input files,
with a timeout of 100ms. Unfortunately, it leaves a lot of zombie processes
around, probably due to the fact that terminateProcess fails to terminate
them, even though eprover terminates on SIGTERM.

I have tried to use System.Timeout.timeout around readProcess, but without
surprise it did not work. Another way of doing it is to use the timeout
from gnu-coreutils, but the timeout resolution is in seconds (same with
eprover's flag --cpu-limit). Any ideas how I could write my code to get a
clean termination of this process?

Best,
Dan Rosén
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe