C program Kills cron daemon

[Sarcom IS]

I have a program that creates child processes. To ensure that these processes are closed when the parent stops execution I am trapping SIGINT, SIGTERM and SIGQUIT. When either of these 3 signals are received I send a kill(0, SIGKILL) to stop any lingering child processes. Along with any child process the cron daemon consitantly goes down with them. Despite the obvious solution of stop running this program as root, which should not have happend and has already been remedied, why is this kill going after the cron. Shouldn't the 0 only send a SIGKILL to childs of like PID to the parent. The program is started as a daemon and has the init parent PID of 1. If the problem were that the parent PID is 1 then I would think I would see many more processes die then just the cron daemon everytime. Any help on this subject would be appreciated.

Thanks in advance

-Mike

[Steven E. Protter]

Shalom Mike,

I would have to see your code to answer the question.

I'm betting though its bad code.

SEP

[A. Clay Stephenson]

First of all pull out a baseball bat and hit yourself over the head with it. Only as an absolute last resort should you send a SIGKILL (kill -9) to a process. Start with the kinder, gentler SIGTERM, then iSIGQUIT, SIGHUP, then SIGINT, then SIGSEGV (which is almost as sure a kill as SIGKILL) and finally SIGKILL. You should send a kill(0,pid) to each process to see if the pid is still valid before escalating the level of the signal.

Your fundamental error was not immediately doing a setsid() before spawning any child processes so that a new process group is set up. It is then safe to do your kill(0,SIGTERM). The setsid() should occur very early in your cron'ed program. Man setsid for details.

[Sarcom IS]

Yes the SIGKILL should only be used as a last resort and certainly never placed within a program.
The program was called from a start script, executed by the cron, and even though the PPID is now 1 because the script that started it has finished, the program is still tied to the cron? If the cron goes down say 70% of the time the program in question receives an interrupt, why isn't the cron dying the other 30% of the time?

[harry d brown jr]

The issue appears to be similar to one I resolved year back when we had a security program that attempted to kill lingering child processes. Unfortunately, the PPID was 1, which KILLED every process with a PPID of 1.

cron's ppid is 1

It's your code. You should not kill processes with a PPID = 0 or 1. If a parent dies, the child gets assigned to init, hence ppid=1!

Find a better way to locate and kill the actually related processes.

live free or die
harry d brown jr

[A. Clay Stephenson · Accepted solution]

Do the setsid() that will fix you although to absolutely, properly do this you should:

int main(int argc, char *argv[])
int cc = 0;
pid_t pid = 0;
{
pid = fork();
if (pid == 0)
{ /* child process */
setsid();
chdir("/"); /* so that filesystems can umount */
/* Now your real work goes here */
exit(cc);
}
else
{ /* parent process; just exit */
exit(cc);
}
} /* main */

if you fork() and then do the setsid(), you are assurred of setting up a new process group so your kill(0,SIGXXX) will not clobber cron.

[Sarcom IS]

Thank you all for your responses.