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.

Krishanu

[ Post a follow-up to this message ]

On 4=D4=C228=C8=D5, =C9=CF=CE=E75=CA=B107=B7=D6, krishanu.debn...@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 =3D fork();
> if (pid =3D=3D 0) {
>   int st =3D system(exe1);
>   if (st !=3D 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 !=3D EXIT_SUCCESS
> even if exe1 returns EXIT_SUCCESS;
>
> Any sort of clue will be helpfull.

http://www.opengroup.org/onlinepubs...hap02_04.html#=
tag_02_04

SIG_IGN
Ignore signal.

Delivery of the signal shall have no effect on the process. The
behavior of a process is undefined after it ignores a SIGFPE, SIGILL,
SIGSEGV, [RTS] [Option Start]  or SIGBUS [Option End] signal tha
t was
not generated by kill(), [RTS] [Option Start] sigqueue(), [Optio
n End]
or raise().

The system shall not allow the action for the signals SIGKILL or
SIGSTOP to be set to SIG_IGN.

Setting a signal action to SIG_IGN for a signal that is pending
shall cause the pending signal to be discarded, whether or not it is
blocked.

If a process sets the action for the SIGCHLD signal to SIG_IGN,
the behavior is unspecified, [XSI] [Option Start]  except as specifi
ed
below.

If the action for the SIGCHLD signal is set to SIG_IGN, child
processes of the calling processes shall not be transformed into
zombie processes when they terminate. If the calling process
subsequently waits for its children, and the process has no unwaited-
for children that were transformed into zombie processes, it shall
block until all of its children terminate, and wait(), waitid(), and
waitpid() shall fail and set errno to [ECHILD]. [Option End]

[RTS] [Option Start] If the Realtime Signals Extension option is
supported, any queued values pending shall be discarded and the
resources used to queue them shall be released and made available to
queue other signals. [Option End]

[ Post a follow-up to this message ]

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 ***

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

On Apr 28, 7:07 am, krishanu.debn...@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.
>
> Krishanu

Under system V and Unix98 the child of a process does not become a
zombie if the process sets the disposition of
SIGCHLD to SIG_IGN - this works only under unix V and 98 ,
to handle zombies is to catch SIGCHLD and call wait or waitpid.


zaher el siddik
http://elsiddik.blogspot.com/

[ Post a follow-up to this message ]

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.

[ Post a follow-up to this message ]

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

[ Post a follow-up to this message ]

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
>

[ Post a follow-up to this message ]

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 ***

[ Post a follow-up to this message ]