Fork and then exec problem with signals

Applications Programming
1

Hi All,

In my program i am handling SIGHUP signal. In the handler i fork and then exec on child process same binary file which is running. Parent process will die after 10 mins.
Now my child process which was exec with same binary file is not receiving SIGHUP signal. Below is the progran code:

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
pid_t pid;
void sigHandler(int signo)
{
  printf("[%d]signal received \n",getpid());
  pid = fork();
  if(pid  ==  0)
  {
    printf("[%d] I m child process \n",getpid());
    signal(SIGHUP,sigHandler);
    execl("./chainNew", "chainNew", (char *)0);
  }
  else if(pid > 0)
  {
    printf("[%d] I m Parent process \n",getpid());
    <Logic so i will exit after 10 mins.>
    exit(0);
  }
  else
  {
    printf("[%d]  Fork Failed \n",getpid());
  }
}
int main ()
{
  signal(SIGHUP,sigHandler);
  signal (SIGCHLD, SIG_IGN);
  while (1)
  {
    printf("[%d] Waiting for SIGHUP \n",getpid());
    sleep(2);
  }
}
2

Why would it get SIGHUP when SIGHUP has already been handled?

3

Hi ,

As parent will die after 10 mins, i have a requirement where by now child will have to receive SIGHUP signal and repeat the process by creating further child of it.
As soon this grand child will be created the previous child will die after 10 mins.
this way it will go on....

But as the parent child is dying my child process is not receiving SIGHUP signal.

Hope u understand the problem.

4 
else if(pid > 0)
  {
    printf("[%d] I m Parent process \n",getpid());
    <Logic so i will exit after 10 mins.>
    exit(0);
  }

as posted this will exit immediately on the first SIGHUP, the <Logic ...> part will not compile, so you might want to show that

5

Yes, Find below the code.. :slight_smile:

#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
pid_t pid;
void sigHandler(int signo)
{
  printf("[%d]signal received \n",getpid());
  pid = fork();
  if(pid  ==  0)
  {
    printf("[%d] I m child process \n",getpid());
    signal(SIGHUP,sigHandler);
    execl("./chainNew", "chainNew", (char *)0);
  }
  else if(pid > 0)
  {
    printf("[%d] I m Parent process \n",getpid());
    sleep(60*10);
    exit(0);
  }
  else
  {
    printf("[%d]  Fork Failed \n",getpid());
  }
}
int main ()
{
  signal(SIGHUP,sigHandler);
  signal (SIGCHLD, SIG_IGN);
  while (1)
  {
    printf("[%d] Waiting for SIGHUP \n",getpid());
    sleep(2);
  }
}
6

Are execl(), printf(), and sleep() all async-signal safe?

I don't think execl() is, and I'd bet a lot that printf() isn't, and whether or not sleep() is async-signal safe probably depends on the implementation.

And FWIW, the custom signal-handler will not propagate across any of the exec()-type calls:

7

When you install any signal handler, they are just installed and not executed untill the signal is received by them.

Now from your code its clear that you are not creating any child inside the main(). However, the SIGHUP is handled, what does it mean is that untill the calling shell program exits; this process is not going to get SIGHUP rather it runs in the while(1) only.

Now when you exit the bash (or whatever shell you use) itself , the SIGHUP handler gets called (you might not been able to see this after you exited) and here a child gets created which inturn calls execl() to replace the child process memory area with a new binary. In this process, only the PCB is kept by the scheduler but with the EIP reset as well as other execution stack pointers along with the binary text. Hence whatever signals this new binary code has handled only works and not the earlier haldlers hold good.

It means the parent now exits after a sleep of 60 seconds and the child is all togather a new executable with a overridden signal handlers.

Now lets examine a few more cases:
1) This new binary has not handled SIGHUP -means the default disposition would apply, and you won't see your sighandler executing.

2) This new binary has a different handler for SIGHUP -it'll execute only that and not the above signalhandler which you wrote.

3) This new binary is the same your executable -It should go in the execution scenario which you are expecting, however there is a default timeout is associated with the signal handlers when the Linux kernel executes them asychronously. Hence the fork() and the sleep of 60 seconds inside the handler is not advicable; instead use vfork() and a sleep of not more than a few hundred miliseconds.

I feel you should use a different terminal to see the results or call bash on your default the login shell prompt before starting your program in the background (& option) and then exit bash to see the results.

1 Like