On Wed, Feb 23, 2000 at 11:44:39AM +1100, Angus Lees wrote:
> On Tue, Feb 22, 2000 at 03:06:59PM +1100, Cameron Simpson wrote:
> > If you're going to fork a process you no longer have any interest in
> > (such as forking a web browser for the user) then it's better to do
> > this extra fork to make the browser a child of init rather than, say,
> > the window manager.
>
> hmm.. wouldn't that make it a different process group?
no, the child stays in its process group
> does xdm use process groups (or parent/child relationship) to kill the
> user's processes on an "exit session" (wmaker's terminology) logout?
well, the kernel uses these things to do this; xdm is just a
process that happens to start a login shell for you and that shell
has a parent-child or process group relationship to most of what you run
from that point on.
There are two definitions of 'session' here: one is a kernel structure
referring to a set of process groups (see APUE section 9.5), and is
used eg. to kill off groups of processes started by a particular
login. The other is an X11 concept referring to a similar thing, but
not managed by the kernel -- it is managed by the window manager, or
a dedicated session manager (see X vol 1 sec 2.1.5). The latter is more
relevent here, and for you it is window maker that manages the X
session. X session management is not just about making sure all your
processes get killed off, it is also about remembering window placement
and even application state.
xdm does start a kernel 'session', but I don't think that's entirely
relevent here (it is more so for console logins).
> as a sysadmin i often find it useful to see that eg. netscape is
> running as a child process of which particular login session. if
> everything was orphaned you'd lose that information..
your wm/launcher should orphan applications (as Cameron said above).
They'll still stay in the same process group and session. You can
check these with 'ps j'.
eg. here's some of my current session -- you follow the numbers
through :) fields shown are PPID (parent process id), PID (pid :),
PGID (process group id), SID (session id), TPGID (foreground process
group id of controlling terminal)
$ ps xjf
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
790 1106 1106 782 ? -1 S 707 0:00 bash -login /etc/X11/gd
1106 1119 1106 782 ? -1 S 707 0:00 /usr/bin/gnome-session
1 3127 1106 782 ? -1 S 707 1:52 xemacs
1 2978 1106 782 ? -1 S 707 0:00 /bin/sh -c cp /dev/null
2978 2980 1106 782 ? -1 S 707 0:18 netscape --library-path
2980 2996 1106 782 ? -1 S 707 0:00 \_ (dns helper)
1 1728 1106 782 ? -1 S 707 0:10 gnome-terminal
1728 1729 1106 782 ? -1 S 707 0:00 gnome-pty-helper
1728 1730 1730 1730 pts/9 16855 S 707 0:00 bash
1730 16855 16855 1730 pts/9 16855 R 707 0:00 \_ ps xjf
hints: 1. I zap my cookies file before running netscape :)
2. a terminal has to set up a pty before running a shell.
3. gnome-session is an X11 session manager (it maintains
application state for gnome apps, which is pretty cool ...)
you'll notice the parent-child relationships are preserved. Do the
same thing on your box, and look at what happens to xdm's children.
You'll see where the UIDs are changed and where new process groups
are started and so forth. (You'll probably also find that xdm
doesn't have a controlling terminal either, and xterm creates itself
one -- similarly to how gdm/gnome works ...)
some things do lose the relationship to your login, eg. if you've
got a fetchmail running in daemon mode it'll be a child of init and
have its own pgid and sid. Hence they still run when you log out of
X. Other things that do the same (such as gnome-panel applets ...)
would hopefully get killed by something else (such as the
gnome-session manager).
Conrad.
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
