LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 09-22-2004, 06:16 PM   #1
feetyouwell
Member
 
Registered: Dec 2003
Location: NC, US
Distribution: Novell Linux Eval (2.6.5)
Posts: 240

Rep: Reputation: 30
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?
 
Old 09-23-2004, 05:22 AM   #2
Hko
Senior Member
 
Registered: Aug 2002
Location: Groningen, The Netherlands
Distribution: Debian
Posts: 2,536

Rep: Reputation: 111Reputation: 111
Re: setpgid() question

Quote:
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?!?).
 
Old 12-21-2004, 06:43 AM   #3
zaichik
Member
 
Registered: May 2004
Location: Iowa USA
Distribution: CentOS
Posts: 419

Rep: Reputation: 30
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.
 
Old 12-21-2004, 10:59 AM   #4
Hko
Senior Member
 
Registered: Aug 2002
Location: Groningen, The Netherlands
Distribution: Debian
Posts: 2,536

Rep: Reputation: 111Reputation: 111
Quote:
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?
 
Old 12-21-2004, 02:26 PM   #5
zaichik
Member
 
Registered: May 2004
Location: Iowa USA
Distribution: CentOS
Posts: 419

Rep: Reputation: 30
Quote:
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.
 
Old 12-22-2004, 01:11 PM   #6
Hko
Senior Member
 
Registered: Aug 2002
Location: Groningen, The Netherlands
Distribution: Debian
Posts: 2,536

Rep: Reputation: 111Reputation: 111
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"):
Code:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

if (daemon(0,0) < 0) {
    perror("Failed becoming daemon");
    exit(1);
}
Also, here's a document about daemonizing:
http://www.enderunix.org/docs/eng/daemon.php
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Question, Apples Contribution to Open Source + MacOs file structure question Higgy3k Other *NIX 5 07-25-2005 04:23 AM
system logger, single-user, child setpgid errors - Related or Not? coreymc Red Hat 0 04-01-2005 05:17 AM
Not your regular GRUB question - just a short question for a fried MBR!! ziphem Linux - General 3 01-31-2005 01:51 PM
login prompt question & kde scheme question JustinCoyan Slackware 2 06-09-2004 02:02 PM
RE: Suse 8.0 hardware question {newbie question, pls help} Radiouk Linux - Distributions 2 06-04-2002 12:53 PM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 04:12 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration