[26595] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 8723 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Nov 30 11:05:31 2005

Date: Wed, 30 Nov 2005 08:05:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Wed, 30 Nov 2005     Volume: 10 Number: 8723

Today's topics:
    Re: Killing all child processes upon parent exit (Anno Siegel)
    Re: Killing all child processes upon parent exit <snort_sam@yahoo.com>
    Re: Killing all child processes upon parent exit (Anno Siegel)
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: 30 Nov 2005 11:41:39 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Killing all child processes upon parent exit
Message-Id: <dmk35j$qog$2@mamenchi.zrz.TU-Berlin.DE>

bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
> Anno Siegel wrote:
> > bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
> > 
> >>Anno Siegel wrote:
> >>
> >>>bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
> >>>
> >>>
> >>>>Hi,
> >>>>
> >>>>Could anyone please tell me how to kill all child processes when parent 
> >>>>exit?
> >>>
> >>>
> >>>What's the problem?  You have the PID, Perl has the kill() function.
> >>>
> >>>Anno
> >>
> >>Yes I have added the kill() function in the signal_handler(), is this a 
> >>proper way to add kill() function in signal handler?
> > 
> > 
> > In which signal handler?  That doesn't make sense.  A signal handler is
> > activated when the process receives a signal.  You want to *send* a
> > signal when the process exits, so call kill() when it exits.
> > 
> have you look thru my server code?

No.  You gave us 95 lines of code with no indication how it relates
to your question.  I haven't read it.

> the signal handler is at the end of 
> the server code. I want to kill all its child processes when the server 
> code received an interrupt signal.

That would kill the children only if the process itself is killed by
that specific signal.  You can do that, but I'd still suggest taking
care of the children in an END block.  You must still catch the signals
you expect to receive because an uncaught exception bypasses END.  It
suffices to catch them unspecifically with "sub { die }".

Anno
-- 
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article.  Click on 
"show options" at the top of the article, then click on the 
"Reply" at the bottom of the article headers.


------------------------------

Date: Wed, 30 Nov 2005 23:11:11 +1100
From: bsder <snort_sam@yahoo.com>
Subject: Re: Killing all child processes upon parent exit
Message-Id: <438d96e2@news.rivernet.com.au>

Anno Siegel wrote:
> bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
> 
>>Anno Siegel wrote:
>>
>>>bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
>>>
>>>
>>>>Anno Siegel wrote:
>>>>
>>>>
>>>>>bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>Could anyone please tell me how to kill all child processes when parent 
>>>>>>exit?
>>>>>
>>>>>
>>>>>What's the problem?  You have the PID, Perl has the kill() function.
>>>>>
>>>>>Anno
>>>>
>>>>Yes I have added the kill() function in the signal_handler(), is this a 
>>>>proper way to add kill() function in signal handler?
>>>
>>>
>>>In which signal handler?  That doesn't make sense.  A signal handler is
>>>activated when the process receives a signal.  You want to *send* a
>>>signal when the process exits, so call kill() when it exits.
>>>
>>
>>have you look thru my server code?
> 
> 
> No.  You gave us 95 lines of code with no indication how it relates
> to your question.  I haven't read it.
> 
> 
>>the signal handler is at the end of 
>>the server code. I want to kill all its child processes when the server 
>>code received an interrupt signal.
> 
> 
> That would kill the children only if the process itself is killed by
> that specific signal.  You can do that, but I'd still suggest taking
> care of the children in an END block.  You must still catch the signals
> you expect to receive because an uncaught exception bypasses END.  It
> suffices to catch them unspecifically with "sub { die }".
> 
> Anno

I just want to follow C traditional style. There is no END style in C 
anyway. well.. may be good just put kill() in the END block..

Thanks
Sam


------------------------------

Date: 30 Nov 2005 13:41:30 GMT
From: anno4000@lublin.zrz.tu-berlin.de (Anno Siegel)
Subject: Re: Killing all child processes upon parent exit
Message-Id: <dmka6a$31i$1@mamenchi.zrz.TU-Berlin.DE>

bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
> Anno Siegel wrote:
> > bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
> >>Anno Siegel wrote:
> >>>bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:
> >>>>Anno Siegel wrote:
> >>>>>bsder  <snort_sam@yahoo.com> wrote in comp.lang.perl.misc:

[...]

> >>>>>>Could anyone please tell me how to kill all child processes when parent 
> >>>>>>exit?

[...]

> >>the signal handler is at the end of 
> >>the server code. I want to kill all its child processes when the server 
> >>code received an interrupt signal.
> > 
> > 
> > That would kill the children only if the process itself is killed by
> > that specific signal.  You can do that, but I'd still suggest taking
> > care of the children in an END block.  You must still catch the signals
> > you expect to receive because an uncaught exception bypasses END.  It
> > suffices to catch them unspecifically with "sub { die }".
> > 
> > Anno
> 
> I just want to follow C traditional style. There is no END style in C 
> anyway. well.. may be good just put kill() in the END block..

I took a look back at your code now you've said what part of it you
have problems with.  One possible problem is that you set the signal
handler before you fork, so the kids have a (HUP-) handler too.  It
looks to me that the kids should eventually die anyway, but it is
probably not what you want.  Try setting the handler in the parent
only (after fork), or reset it in the kids.

For a Perl solution I'd still prefer END {}, but if you need a prototype
for a C(++) program, by all means debug the sig-handler solution.  Is the
handler actually invoked?  Does it succeed in sending the signal?  What
is the return value of kill?  Do the kids receive the signal?  What
happens if you give an explicit list of pids instead of signalling the
process group?

Anno
-- 
If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article.  Click on 
"show options" at the top of the article, then click on the 
"Reply" at the bottom of the article headers.


------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc.  For subscription or unsubscription requests, send
#the single line:
#
#	subscribe perl-users
#or:
#	unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.  

NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice. 

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V10 Issue 8723
***************************************


home help back first fref pref prev next nref lref last post