-----Original Message-----
From: Olivier Jacques [mailto:[EMAIL PROTECTED]
Sent: 17 October 2006 14:17
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: [Sipp-users] sipp defunct processes
[EMAIL PROTECTED] wrote:
>
> Hello all,
>
> subject: sipp defunct processes
>
> I'm using sipp for a while now (on linux), and wanted to generate some
> syslog messages when things go wrong with the SUT.
>
> As no syslog functionality is built in, I started calling the external
> program logger, and I noticed the same behaviour as found with google
> and copied here below (between the dashes): hanging defunct child
> processes.
>
> As I only subscribed the mailing list a few days ago and google didn't
> indicate a solution to this problem yet, I hope I'm not too late with
> this contribution.
>
> Now, I'm a (very;-) old programmer from the time C++ was not yet
> really used, I found rather quickly what was the problem, but it's
> somewhat hard for me to put all pieces correctly in the code. So I
> made a description how to solve this problem, hoping somebody knowing
> his way in the sipp code but knowing less about unix process handling
> can easily add it. You can find the description below Harry's mail,
> based on the code version 1.1rc6.
>
> Best regards,
>
> MarcVD
>
Marc,
thanks for this contribution.
What about ignoring SIGCLD?
There are two places where SIPp forks: for the "system" command and for
the background mode. In both places, this seems like an acceptable
solution.
What do you think?
Olivier.
--------------------------------------------------
Olivier,
I did some small research for your question, and found three possible
solutions, but, unfortunately, their working depends on the OS.
the solutions are:
1. in-loop (my proposal) = wait for children in program loop
2. in sighandler = install handler for SIGCHLD and wait there for
children
3. ignoring child (different from ignoring the signal, which is what
SIPp does now)
For number three, I found the initialisation
"sigaction(SIGCHLD,SIG_NOWAIT)" should work on Solaris. Unfortunately I
don't find any resembling definition *_NOWAIT on my linux box. There is
a note on my linux man page for "wait", talking about SA_NOCLD-WAIT or
setting SIGCHLD action to SIG_IGN, and different options/specifications
for POSIX and later standards, and linux not supporting or conform to it
(rather unclear text). General conclusion: for portable code, this
doesn't seem the best way to go.
The numbers one and two are both viable solutions, where for the first
you need of course a recurring loop in the program, and SIPp has that.
As there is also signal handling in the program, you could also opt for
the second option. But don't forget, in both cases you will need the
internal loop as you might need to get rid of multiple children at the
same time.
My personal solution would always be the first, as I've seen (and made)
already many mistakes with signal handlers, trying to do much too much
internally, and forgetting that the handler can be called anywhere in
the program execution, also while in the middle of a recalculation of
some variables. I checked the SIGUSRx in SIPp, the techique used is
fine. You could indicate in the same way in a SIGCHLD handler that there
is some "waiting" to do:
child_caught=1;
(as alternative for my child counter), and conditionally execute the
wait loop in the main program loop (but don't forget to clear the flag
BEFORE the wait loop):
if (child_caught) {child_caught=0; while (waitpid(-1,(int
*)NULL,WNOHANG)>0) ;}
This would be a good implementation of point two, which is not much
different from the first solution.
I like the counter+in-loop more (it can help statistics), and you don't
need to recharge the signal handler (some OSes require that) or watch
out for nasty problems like if you would put the child_caught=0 after
the while and see you last child still hanging around. But I leave the
choice to you.
So that's it for the system command. For the background mode, you don't
need anything special at all, the code is just fine. In this case, the
death of the parent SIPp process is handled by the process (normally
your shell) used to launch the program, and as the parent SIPp had a
child, that launching process will take over the care for that child. If
you exit the shell, the process above it (e.g. telnetd, inetd or finally
the init process) will continue the care job. That's why all <defunct>s
disappear as soon as the main SIPp dies: the process above does the
cleaning at that moment.
In short, the background code is just fine, only the comment that the
child gets the parent pid is not right: the child keeps its pid, but
gets another parent (ppid). The code displaying the childs pid is
correct.
Best regards,
MarcVD
**** DISCLAIMER ****
http://www.belgacom.be/maildisclaimer
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sipp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sipp-users
