Unix Programming - Re: strange behaviour

Author

Re: strange behaviour

Barry Margolin

2007-04-28, 4:09 am

In article <1177708055.830427.256610@r3g2000prh.googlegroups.com>,
krishanu.debnath@gmail.com wrote:

> Hello,
>
> I am facing a strange problem when I set SIGCHLD to SIG_IGN to clear
> zombie.
>
> I have a code like this
>
>
> int func() {
>
> ....
> signal(SIGCHLD , SIG_IGN);
> ...
> int pid = fork();
> if (pid == 0) {
> int st = system(exe1);
> if (st != EXIT_SUCCESS) {
> assert(0);
> exit(0); // _exit(0) is advisable ?
> }
> else {
> // parent code
> }
> ....
> return 0;
> }
>
> Now when I run this in different machine(actually in lsf) I am getting
> assert few times
> though exe1 returns EXIT_SUCCESS. And this only happens if I call
> signal(SIGCHLD , SIG_IGN); else it runs fine everytime.
>
> I heard in some systems setting SIGCHLD to SIG_IGN is undefined(?). Is
> that a problem? Or what else can make the value of st != EXIT_SUCCESS
> even if exe1 returns EXIT_SUCCESS;
>
> Any sort of clue will be helpfull.

My signal(3) man page says:

If a process explicitly specifies SIG_IGN as the action for the
signal SIGCHLD, the system will not create zombie processes when
children of the calling process exit. As a consequence, the
system will discard the exit status from the child processes. If
the calling process subsequently issues a call to wait(2) or
equivalent, it will block until all of the calling process's
children terminate, and then return a value of -1 with errno set
to ECHILD.

The system(3) function uses wait(2) to get the exit status of the shell
process. As the above indicates, setting SIGCHLD to SIG_IGN causes this
wait() call to return -1 instead of the process's exit status.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

krishanu.debnath@gmail.com

2007-04-28, 4:09 am

Barry Margolin wrote:
> In article <1177708055.830427.256610@r3g2000prh.googlegroups.com>,
> krishanu.debnath@gmail.com wrote:
>
>
> My signal(3) man page says:
>
> If a process explicitly specifies SIG_IGN as the action for the
> signal SIGCHLD, the system will not create zombie processes when
> children of the calling process exit. As a consequence, the
> system will discard the exit status from the child processes. If
> the calling process subsequently issues a call to wait(2) or
> equivalent, it will block until all of the calling process's
> children terminate, and then return a value of -1 with errno set
> to ECHILD.
>
> The system(3) function uses wait(2) to get the exit status of the shell
> process. As the above indicates, setting SIGCHLD to SIG_IGN causes this
> wait() call to return -1 instead of the process's exit status.

I see. I didn't know this, thank you. Now I have following question:

1> If I move the call to signal(SIGCHLD, SIG_IGN) to else part, do I get
zombie? Because it is possible child process will execute before
execution of signal(SIGCHLD, SIG_IGN) call.

2> In my original program, in child process, if I reset the SIGCHLD
signal to it's default behavior by calling signal(SIGCHLD, SIG_DFL).
Will it fix the problem?

Krishanu

Martin Vuille

2007-04-28, 8:03 am

Barry Margolin <barmar@alum.mit.edu> wrote in
news:barmar-3E23B1.21454627042007@comcast.dca.giganews.com:

> My signal(3) man page says:
>
> If a process explicitly specifies SIG_IGN as the action for
> the signal SIGCHLD, the system will not create zombie
> processes when children of the calling process exit. As a
> consequence, the system will discard the exit status from
> the child processes. If the calling process subsequently
> issues a call to wait(2) or equivalent, it will block until
> all of the calling process's children terminate, and then
> return a value of -1 with errno set to ECHILD.
>
> The system(3) function uses wait(2) to get the exit status of
> the shell process. As the above indicates, setting SIGCHLD to
> SIG_IGN causes this wait() call to return -1 instead of the
> process's exit status.
>

I may be wrong, but it is my understanding that system(3) blocks
SIGCHLD while it is executing so that the wait(2) will not fail for
that reason.

MV

--
I do not want replies; please follow-up to the group.

krishanu.debnath@gmail.com

2007-04-28, 7:04 pm

Barry Margolin wrote:
> In article <1177708055.830427.256610@r3g2000prh.googlegroups.com>,
> krishanu.debnath@gmail.com wrote:
>
>
> My signal(3) man page says:
>
> If a process explicitly specifies SIG_IGN as the action for the
> signal SIGCHLD, the system will not create zombie processes when
> children of the calling process exit. As a consequence, the
> system will discard the exit status from the child processes. If
> the calling process subsequently issues a call to wait(2) or
> equivalent, it will block until all of the calling process's
> children terminate, and then return a value of -1 with errno set
> to ECHILD.
>
> The system(3) function uses wait(2) to get the exit status of the shell
> process. As the above indicates, setting SIGCHLD to SIG_IGN causes this
> wait() call to return -1 instead of the process's exit status.
>

Looks like in our source code we can't use signal(SIGCHLD, SIG_IGN). And
I can't catch SIGCHLD to call signal_handler. I can use the waitpid
function though with WNOHANG option.(I don't need the status information
of child, I don't want to wait to child terminates, I just don't want
the zombies)

Consider this:

int pid = fork();
if (pid == 0) {
[code]
exit(0);
}
else {
waitpid(pid, NULL, WNOHANG);
......

Now my understanding is:

As waitpid is non-blocking here,
1> If child terminates before waitpid is called, I avoid zombie.
2> If waitpid is called before child terminates, will be the child
zombie later when it terminates before parent terminates?

Krishanu

krishanu.debnath@gmail.com

2007-04-28, 7:04 pm

krishanu.debnath@gmail.com wrote:
> Barry Margolin wrote:
>
> Looks like in our source code we can't use signal(SIGCHLD, SIG_IGN). And
> I can't catch SIGCHLD to call signal_handler. I can use the waitpid
> function though with WNOHANG option.(I don't need the status information
> of child, I don't want to wait to child terminates, I just don't want
> the zombies)
>
> Consider this:
>
> int pid = fork();
> if (pid == 0) {
> [code]
> exit(0);
> }
> else {
> waitpid(pid, NULL, WNOHANG);
> .....
>
>
> Now my understanding is:

Well, I got the answer after reading manual.

>
> As waitpid is non-blocking here,
> 1> If child terminates before waitpid is called, I avoid zombie.
Yes.

> 2> If waitpid is called before child terminates, will be the child
> zombie later when it terminates before parent terminates?
Yes.

>
> Krishanu
>

Barry Margolin

2007-04-28, 10:05 pm

In article <4632f07a$0$90266$14726298@news.sunsite.dk>,
krishanu.debnath@gmail.com wrote:

> 2> In my original program, in child process, if I reset the SIGCHLD
> signal to it's default behavior by calling signal(SIGCHLD, SIG_DFL).
> Will it fix the problem?

I think that's the best solution.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

Sponsored Links