Unix Programming - Process Groups: How to?

Author

Process Groups: How to?

Kenny McCormack

2004-05-24, 10:40 am

A common problem that one faces when designing systems that involve more
than one process is: How to make sure that all the pieces go away when the
thing crashes. I.e., who here has not had the experience of building
a complex system, and it crashes and leaves bits and pieces still running?

Give that as intro, my question is: How exactly do you use the concept of
a process group to achieve this? I know that a login shell is usually both
a session leader and a process group leader, and that when the login shell
dies, a SIGHUP is sent to all the processes in the session (this is a good
thing). I also know that the original concept of "process groups" has been
expanded to include both "process groups" and "sessions" - and that session
is somehow a superset of "process group".

It seems from my reading of the man pages (intro, setpgid, setpgrp, setsid,
etc), that you should be able to do: setpgid(0,0) and that should make the
current process a process group leader (but still a member of the login
"session"). This should have the effect that child processes of this
process will get HUP'd when this process goes away. However, my limited
testing has not borne this out.

Here is a test (don't bother nitpicking the sloppy C):

main()
{
setpgid(0,0);
execl("/bin/sh","sh",0);
}

This should create a shell that is a process group leader and should behave
as described in the previous paragraph. Correct?

(Testing under Linux and/or Solaris)

Barry Margolin

2004-05-24, 11:43 am

In article <c8svpu$il5$1@yin.interaccess.com>,
gazelle@yin.interaccess.com (Kenny McCormack) wrote:

> A common problem that one faces when designing systems that involve more
> than one process is: How to make sure that all the pieces go away when the
> thing crashes. I.e., who here has not had the experience of building
> a complex system, and it crashes and leaves bits and pieces still running?
>
> Give that as intro, my question is: How exactly do you use the concept of
> a process group to achieve this? I know that a login shell is usually both
> a session leader and a process group leader, and that when the login shell
> dies, a SIGHUP is sent to all the processes in the session (this is a good
> thing). I also know that the original concept of "process groups" has been
> expanded to include both "process groups" and "sessions" - and that session
> is somehow a superset of "process group".
>
> It seems from my reading of the man pages (intro, setpgid, setpgrp, setsid,
> etc), that you should be able to do: setpgid(0,0) and that should make the
> current process a process group leader (but still a member of the login
> "session"). This should have the effect that child processes of this
> process will get HUP'd when this process goes away. However, my limited
> testing has not borne this out.

No, that's not what process groups do. Sessions work like that, but
process groups don't.

Process groups are useful for the following things:

When you explicitly give a negative PID argument to the kill() function,
the absolute value is used as a process group ID, and the signal is sent
to all the processes in that group.

A terminal can have a process group associated with it. If a process
from another group tries to read or write it, it gets a SIGTTIN or
SIGTTOU signal (terminal modes enable this mechanism). This is
generally used by process control shells to distinguish between
foreground and background jobs.

When you type a keyboard interrupt character, the signal is sent to all
the processes in the associated process group.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Sponsored Links