ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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?
Originally posted by feetyouwell [...] 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?
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?!?).
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.
Originally posted by zaichik
Hope this is still relevant or helpful.
Yes, to me this is still relevant and helpful. Thanks.
This does pop up a few new questions to me...
Quote:
Process groups are for the purpose of grouping together a number of different processes that will all respond to the same signals.
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?
Quote:
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.
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?
Originally posted by Hko 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?
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:
Code:
int kill(int pid, int sig);
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.
Quote:
What happens when a signal is send to one of the members that is not the group leader?
As above, all members of the process group will get the signal.
Quote:
Will there allways be a leader?
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.
Quote:
What is this mechanism used for?
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.
Quote:
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?
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.
Quote:
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).
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.
Quote:
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.
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"):
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.