Sapa,
that is not the point. who kills the children ? i.e. - where is the piece of code responsible for it in the kernel ?
Main Topics
Browse All TopicsI wrote the simplest piece of code, in which a process creates a new one and they both wait for input from the keyboard. Now, when killing the parent process ( by sending it SIGTERM ), the child process is killed too. I can't figure out who kills it and why. Does anyone knows the answer ?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
do a double fork and exit the middle process.. this will keep the parent and
the child seperate. (the child will be inherited by init) and killing the parent
will not result in the child also exiting.
(the child was also killed in your case because.. they both were sharing the
common address space.)
Cheers.
yzach:
show your programm code, and the command you have used for sending SIGTERM, please. Signals may be sent to one of these: pgocess, process group, and session leader. If you interested of kernel code, look into /usr/src/linux/kernel/sign
- Sapa
edvinkv: double-fork is only a trick to remove process from the current process group. setsid() make the same without additional tricks. The same address space may be shared between different processes in different groups and it take no significance.
- Sapa
Is it also possible that killing a session leader (which detaches the controlling terminal from the session) causes all the processes in the session to get a SIGHUP? SIGHUP is often fatal. And the session leader is usually the ancestor of all the processes in the session.
I read all this session/process group/controlling terminal stuff in the kernel once, but I don't remember where.
It seemed strange to me that a SIGHUP signal would be sent only to processes that are stopped when the parent terminates, so I took a look at the process exit code, and found out it isn't quite like that. If any process in a process group is stopped, all the processes in the group get the signal. They also get a SIGCONT, so if they are stopped, they have a chance to start up and deal with the SIGHUP. This behavior doesn't make any more sense to me than the other, but that appears to be what it is.
I also discovered that any process group that gets orphaned gets the SIGHUP, and if the exiting process is session leader, it calls disassociate_ctty(), which sends SIGHUPs to the other processes in the session, like I suspected. disassociate_ctty() is in the tty device driver, drivers/char/tty_io.c.
So considering that a SIGHUP signal often terminates a process (by default, in fact), I think this may be the answer to the question.
No comment has been added lately, so it's time to clean up this TA.
I will leave the following recommendation for this question in the Cleanup topic area:
SPLIT: Sapa{6016451} & bryanh{6041667}
Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
jmcg
EE Cleanup Volunteer
Business Accounts
Answer for Membership
by: SapaPosted on 2001-04-17 at 14:56:54ID: 6015247
man 2 setsid
man 2 setpgrp
- Sapa