Does a process goes back to same location after handling SIGTERM ?

murugesan · 09-12-2005, 08:28 AM

Hi all,

I have a function like

maincode:

Code:

           struct sigaction act;
           act.sa_handler = SIGACTION_SIG_CAST (mychildhandler);
           sigemptyset(&act.sa_mask);
           act.sa_flags = 0;
           if (sigaction(SIGTERM, &act, (struct sigaction *)0) == -1)
                       cout << "FAILED :( \n";
           
           // Do the Same for myPARENThandler
           .
           fork()
           .
           .
           
           // MAKE parent to run in an infinite loop and make child to execute some task and quit.

The signal handlers are :

Code:

           void mychildhandler(int signalnum )
           {
                      cout<< "Entering into mychildhandler \n";
                      if (signalnum != SIGTERM )
                                 return;
                      myfun();
                      cout<< "Finished with mychildhandler \n";
                      return;
           }

           void myPARENThandler(int signalnum )
           {
                      cout<< "Entering into mychildhandler \n";
                      if (signalnum != SIGTERM )
                                 return;
                      myfun();
                      cout<< "Entering into mychildhandler \n";
                      exit(1);
           }

When the parent or child receives SIGTERM, myPARENThandler/mychildhandler gets executed. After the execution of "exit(1);" the parent gets exited.

The child has to do some task. In the mid of the task when the child receives SIGTERM, the above function (mychildhandler) gets executed. I am getting the output "Finished with mychildhandler ". After this statement nothing is getting printed (remember that the child is doing some task and is printing a line after its execution gets completed.)

Now my question is
After calling the mychildhandler function does the child goes back to the original location where it received the sigterm?
If it goes back how can I make sure that it goes back ?
If it does not goes back how can I make it to go back to the location where it left ?

Regards,
Murugesan

Hko · 09-12-2005, 11:04 AM

Signal handler functions do not survive a fork(). So you need to call fork() before sigaction() if you want the child process to handle the signal.

murugesan · 09-12-2005, 11:44 PM

Hi Hko,

Thanks for the reply. The mychildhandler function is getting called in my case. As I said my questions are :

After calling the mychildhandler function does the child goes back to the original location where it received the sigterm?
If it goes back how can I make sure that it goes back ?
If it does not goes back how can I make it to go back to the location where it left ?

-Murugesan

primo · 09-13-2005, 03:57 AM

Quote:

Originally posted by Hko
Signal handler functions do not survive a fork(). So you need to call fork() before sigaction() if you want the child process to handle the signal.

Signal handlers DO survive fork()'s. To quote Richard Stevens:

Quote:

When a process calls fork the child inherits the parent's signal dispositions. Here, since the child starts off with a copy of the parent's memory image, the address of a signal-catching function has meaning
in the child.

But:

Quote:

When a program is execed the status of all signals is either default or ignore. Normally all signals are set to their default action, unless the process that calls exec is ignoring the signal. Specifically, the exec functions change the disposition of any signal that are being caught to their default action and leave the status of all other signals alone. (Naturally a signal that is being caught by a process that calls exec cannot be caught in the new program, since the address of the signal-catching function in the caller probabllly has no meaning in the new program file that is execed.)

Also, in some cases it's best to install signals handlers before a fork() because of the tiny window or race between execution of any of the processes involved and the installation of the signal handler itself: a signal could be delivered in between and will cause its default action (with SIGTERM it would be to terminate the process). The parent and the child may share a signal handler. In this case it would be easy with a global pid_t variable-

Quote:

Originally posted by murugesan
After calling the mychildhandler function does the child goes back to the original location where it received the sigterm?

It goes back to the original location. The following guidelines are a must:
1- Save errno and restore it later. Use something like "int save_errno = errno;" and "errno = save_errno;" in the beginning and the end of the signal handler, respectively.
2- Some system calls may return EINTR if they were interrupted by a catched / ignored signal, or you may use SA_RESTART in act.sa_flags
3- Ignore all signals on critical sections of code with setprocmask(2)

Note that both handlers are saying: "Entering into mychildhandler \n"

bigearsbilly · 09-13-2005, 04:29 AM

Quote:

After calling the mychildhandler function does the child goes back to the original location where it received the sigterm?

why don't you experiment and find out?
It's the only way to learn.

Hko · 09-13-2005, 06:35 AM

Quote:

Originally posted by primo
Signal handlers DO survive fork()'s. To quote Richard Stevens:

"man fork" (on Debian sarge) says:

Quote:

fork creates a child process that differs from the parent process only in its PID and PPID, and in the fact that resource utilizations are set to 0. File locks and pending signals are not inherited.

You're right.
I've misinterpreted the bold sentence of the man page. Sorry.

murugesan · 09-13-2005, 07:44 AM

Hi primo,

Quote:

2- Some system calls may return EINTR if they were interrupted by a catched / ignored signal, or you may use SA_RESTART in act.sa_flags

This helped me in resolving the issue.

Thanks a lot.

Thanks for others too for posting your comments.

Regards,
Murugesan