system function in linux

Navjot Arora · 08-17-2012, 06:55 AM

Hi All,

In the below code , when system function get executed (in LINUX and compiled with g++) , it will send the SIGCHLD signal to process (from which it is called) which doesn't happen in solaris code i mean if i run the same code in solaris, system function doesn't send any signal to process from which it is called.As a result of which my process in Linux got hanged.

#include <iostream>
using namespace std;
#include <cstdlib>
#include <signal.h>
void sigHandler(int sgnNbr)
{
cout <<"Signal " << sgnNbr << "caught" << endl;
system("echo $HOSTNAME");
exit(1);
}
int main()
{
signal(SIGCHLD,sigHandler);
system("echo $HOSTNAME");
return 0;
}

my question is :
1) why the process get hanged in the above case
2) why in solaris , system function doesnt send any signal

and my last question which is related to my real application is :

Actually , in my real application , some other process sending the SIGKILL signal to my process and in signal handler i am killing the one process using system function as a result it got hanged(which is similar to the above scenario). Is there any way to overcome this.

Please let me know if my query is not clear

dwhitney67 · 08-17-2012, 07:44 AM

No process is able to catch a SIGKILL (9) signal. Can you please elaborate as to what the issue is with your real application?

As for your sample application, why are you calling system() from within the signal handler?? Duh... that is going to generate another SIGCHLD, and... in other words, the exit() function call in the signal handler will never be reached.

P.S. I should have added that a system() call will fork a child-process; hence when that child exits, a SIGCHLD signal is issued.

Navjot Arora · 08-17-2012, 09:10 AM

Hi,

Sorry that is SOGABRT not SIGKILL

the above program i wrote just to simulate and explain the behavior which is happening in my application

---------- Post added 08-17-12 at 07:41 PM ----------

read SOGABRT as SIGABRT

theNbomr · 08-17-2012, 09:15 AM

According to

Code:

man 7 signal


       The entries in the "Action" column of the table specify the default action for the signal, as follows:

       Term   Default action is to terminate the process.

       Ign    Default action is to ignore the signal.

       Core   Default action is to terminate the process and dump core.

       Stop   Default action is to stop the process.

       First the signals described in the original POSIX.1 standard.

       Signal     Value     Action   Comment
       -------------------------------------------------------------------------
<...unrelated entries trimmed...>
       SIGCHLD   20,17,18    Ign     Child stopped or terminated

This is described as the POSIX-compliant behavior.

So it seems that for some reason, your program's default signal action has been modified. Since this property is inherited from the parent process, perhaps that is one avenue to explore. Other wise, perhaps the change is an inadvertent side effect of some API that your application is bound to.
It is possible that Solaris does not conform to POSIX standards for this.

The recursive signal handling in your example may be masking or exacerbating the real root of the matter.

--- rod.

Reuti · 08-18-2012, 03:59 PM

Having a look with strace it looks like system() includes a waitpid(). As the first waitpid() is never closed, the second waitpid() in the signal handler can’t be created. At this point it hangs.