レナート   Wunschkonzert, Ponyhof und Abenteuerspielplatz   ﻟﻴﻨﺎﺭﺕ

Posted by Scott Robinson at Mon Nov 26 04:19:56 2007
Do publish a follow-up post if you discover the answer.

I too have always been curious.

Posted by Colin Walters at Mon Nov 26 04:20:13 2007
You have seen the GNU libc docs right?

http://info2html.sourceforge.net/cgi-bin/info2html-demo/info2html?(libc.info.gz)Job%20Control

I wouldn't say I totally understand all this, though I am slowly trying to figure it out, as I figure it's important since I'm implementing a shell...

Posted by Anonymous at Mon Nov 26 04:45:57 2007
For one thing, process groups ensure that when you close your shell (such as by terminating an SSH or X terminal), all of the processes receive a SIGHUP.

Posted by Ray at Mon Nov 26 05:15:30 2007
The Stevens/Rago book goes pretty in depth into this.  You might want to check it out.

The concepts are mainly useful for shells and are for determining which processes get control of the stdin/stdout.

All the process on a command pipe line are in the same process group.  So for instance, with,

cat file | grep keyword | sort | uniq > output &

the entire job is in a process group.  Because of the amperstand, it's a background job. The command prompt is in its own process group which is the foreground process group.

The command prompt and that job are part of the same session.  Each session has a controlling terminal (normally the pty associated with the xterm).  It is defined to be the controlling terminal of the foreground process group.  Processes in background process groups will get sent signals (SIGTTOU and SIGTTIN) if they try to use the session's terminal.

There are some lifecycle details I don't quite remember off hand, too.  I think it's something like if process groups are orphaned (the session leader exits), then they  get sent a hangup signal and get moved to init's session.

Anyway, check out the APUE, it's pretty easy to read and covers all the arcane details.

Posted by Anonymous at Mon Nov 26 10:16:09 2007
The session consists of the association of the processes with a controlling terminal (tty), which typically is not a real (kernel-implemented) terminal but a program that acts as one, then it's implemented by using a pseudo-tty (pty).

Foreground and background is related to processes that you run in the interactive shell; background processes get suspended as soon as they start producing output. There's also a special permission that allows you to send ctrl-c to a setuid process, as long as it is in your session.

The leader gets signaled if one of the child processes dies, that's as far as I know the only difference.

If any process dies (regardless of sessions) its childs become orphans. One of the tasks of the init process is to 'adopt' these orphans. This is important because of the signaling when the child processes exit. As long as a child process' parent hasn't acknowledged the signal, the child cannot be cleaned up (it'll be a zombie process). This is so the exit result of the process doesn't get lost.

Posted by fraggle at Mon Nov 26 22:38:49 2007
I bet it was designed by a committee.

Posted by kenneth topp at Tue Nov 27 06:51:53 2007
a) primary usage of sessions on any machine is delivery of HUP (disconnect) and WNCH (window resizes).  Anyone who creates a daemon should run  setsid to get off the terminal, ignoring signals is adaquate, but wrong.
b) session leader just has difference behavoirs of running setpgid, not better, just different.
c) What does job control persist of besides multicasting signals?  renice(1)
d) And what is "placement in foreground or background" other than delivering signals?  I think this is how processes get access to stdin/stdout/stderr for the tty

e) And I totally don't get POSIX sessions and how they differ from POSIX process groups.  process group == session.