setpgid() question
 

When I used setpgid (pid a, pid a) on a certain pid a whose parent is pid b, then basically pid a started it's own group which is the same number as pid a, then I check on pid a's parent and it's still pid b, is it correct? Should the pid a 's parent at that time become itself?

Re: setpgid() question
 

I'm still a bit puzzled by those "process groups". What is their purpose? Some months ago I searched for this, but could not find much information to clear this up for me.

Anyways, I don't think some PID can become its own parent. Never. The only exception possibly being init, which always has PID 0, and whose only parent can only be the kernel (or itself?!?).

Hi,

Hope this is still relevant or helpful.

Process groups are for the purpose of grouping together a number of different processes that will all respond to the same signals.

Setting the process group id to the same as the process id for a process simply makes that process the process group leader, it does not change the process's parent process id.

Yes, to me this is still relevant and helpful. Thanks.
This does pop up a few new questions to me...

So, if I understand this correctly, when a signal is send to the group leader, all processes that are member of this group will recieve the signal. Is that right?

What happens when a signal is send to one of the members that is not the group leader?
Will there allways be a leader?
What is this mechanism used for?

I can imagine a shell process being the group leader of all processes started from that shell process, so when the shell exits, all processes started by it will receive SIGTERM (or some other signal) as well. But, if this is the case, this could be done also by sending the signals to all processes which are childs or grand-childs of the shell, right?

As I understand it, it depends on how the signal is sent. One condition that generates signals is the kill system call (not the same as the kill shell command). The system call looks like this:

If the pid argument is zero, then the signal is sent to all processes in the sender's process group. So yes, you are correct that a signal sent to the process group leader gets sent to all members of the group; but also, a signal sent to any process in the group gets sent to all.

As above, all members of the process group will get the signal.

Yes, I believe there is always a process group leader, even if there is only one process in the group. Members of a process group can leave the group and become process group leaders of their own groups. When that is the case, the original leader may be left alone in the group, but it will still be the group leader.

Your scenario below is the only purpose I can think of for this mechanism. It is in fact the case that child processes initially belong to the same process group as the parent, but as a child process can change its process group id, it is not always the case that membership in a process group means the processes are all related as parent/child/sibling.

That seems right to me, but to be honest, I have not come across a method for sending a signal to all children (that only means that I have not come across one, not that one doesn't exist). And while I can't think of an example where a process that is not a child process would want to receive all the signals sent to another process, there could be such a situation, in which case sending a signal to all the child processes would not do the trick.

I have come across all this because I am trying to go the other way; I am figuring out how to create a daemon process. In the case of a daemon, we want the child to become its own process group leader, disassociate itself from a control terminal, and not reacquire a control terminal. So I am actually trying to move a process out of a process group, rather than into one.:)

Thank you.
For the remaining things I don't fully understand, I will try fiddling with it.

I think there isn't a kill_all_childs() either. My first thought was that it would be quite easy to recursively walk through the child-processes and kill them. On second thought this is probably not that easy, or at least not efficient. To get the parent of a certain process is easy (getppid()), but there's no easy, efficient way to get all childs of some process.

That is why I ran into it as well. But when I started looking for "process leaders" I didn't find much, and I still didn't know about signals being delivered to all group members.

What I know is that the programming trying to become a daemon should remove itself from any process group that has other members by calling setsid() or setpgrp(). To make sure this succeeds (or at least improve the odds), it should fork(), exit the parent, and have the child live on and call setsid() or setpgrp(). After that, fork() again for some reason, change directory to / and set stdin/out/err to /dev/null.

While reading about this I also ran into session leaders :( Raising new questions...

But there is also the daemon() function which wraps all this. (see "man 3 daemon"):
Also, here's a document about daemonizing:
http://www.enderunix.org/docs/eng/daemon.php