Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re: mod.std.unix P1003 job control proposal (Brett Galloway)
Message-ID: <6192@ut-sally.UUCP>
Date: Sat, 1-Nov-86 18:37:33 EST
Article-I.D.: ut-sally.6192
Posted: Sat Nov  1 18:37:33 1986
Date-Received: Mon, 3-Nov-86 23:42:32 EST
References: <6102@ut-sally.UUCP>
Organization: IEEE P1003 Portable Operating System for Computer Environments Committee
Lines: 85
Approved: jsq@sally.utexas.edu

From: pyramid!nsc!hplabs!hpda!hpisoa1!davel (Dave Lennert)
Date: Wed, 29 Oct 86 10:07:47 -0800

> From: seismo!munnari!yabbie.rmit.oz!rcodi@sally.utexas.edu (Ian Donaldson)
> Date: Tue, 21 Oct 86 10:39:40 EST
> 
> What is the significance of the "saved process group ID"?  How is
> it different to the normal process-group-ID?  Who uses it?

The saved process group ID is analogous to the saved user and group ID's
in System V.  They preserve the original values the process had when
exec'd.  This allows the process to adopt a different value for one
of these ID's and later return to its original value.  Without a "saved"
value, all knowledge of the original value and of the process's rights
to use it are lost.

The saved process group ID value is necessary with job control in the
following scenario:

Root user su's to non-root user whose login shell is a job control shell
(say csh).  Csh resets its process group to a new value (it becomes a
process group leader).  When it terminates or suspends, it needs to
restore both the tty group ID (a process group ID value) and its own
process group ID back to the original values they had at entry.  (This
restores its parent to the foreground.)  Under 4.2 this is no problem
since there are no security checks for this.  Under POSIX there are
security checks based on uid's which normally are allowed since the uid of
the parent process and the csh are identical, but in our scenario would
be disallowed because the uid's don't match.  The saved process group ID
is an alternate security check which allows the above scenario.  See the
security discussion in setpgrp2() and in the POSIX termios proposal.

> > 	     If	the process is a session process group leader, the
> > 	     SIGHUP signal may be sent to each process that has	a
> 			   ^^^ should be replaced by the word "will"
> > 	     process group ID equal to that of the calling process;

"May" is used here to allow 4.2 systems to conform.  4.2 does not
send SIGHUP on process group leader death.

Note that, with a job control shell, all child processes started by
the shell are placed in a different process group than the (process
group leader) shell is in.  Thus when the shell dies, SIGHUP is not
seen by any of the children anyway.

> I disagree with the proposal on the handling of _exit processing for
> job control.  It should be possible to not have to know in advance
> that you wish to log-off and leave something running that you started
> in foreground and later shifted to background.  This is a KEY feature
> of job control.  

This key feature is preserved in the POSIX specification.  Perhaps I
don't understand your statement.

> vhangup() will provide clean terminals on a bsd system,
> and we have improved vhangup further to not just turn off READ/WRITE bits,
> but to actually redirect the file references to /dev/null (which has
> the advantage of also dropping DTR reliably). 
> I see no mention of a vhangup equivalent in this proposal segment, but
> then again, I haven't seen the whole of P1003 either.

vhangup() is indeed desirable.  It is not required in POSIX because it is 
not supported on System V and, indeed, breaks System V compatiblity.
(See my job control paper that was posted in mod.std.unix recently.)

> Children of init that are stopped are also sent SIGHUP's and SIGCONT's.

More correctly, at the time a stopped process is inherited by init (due 
to its parent's death), it is sent SIGHUP and SIGCONT.  POSIX has this
too; see the _exit part of the job control specification.

> Infinite-loop processes don't cause problems with system-response because
> they are automatically niced (something that is long-needed in UNIX systems).

Note that this is NOT desirable on, e.g., realtime systems where that
long running process may be critical.  I'm also getting tired of having
my rwhod reniced automatically.

    Dave Lennert                ucbvax!hpda!davel               [UUCP]
    Hewlett-Packard - 47UX      ihnp4!hplabs!hpda!davel         [UUCP]
    19447 Pruneridge Ave.       hpda!davel@ucb-vax.ARPA         [ARPA]
    Cupertino, CA  95014        (408) 447-6325                  [AT&T]


Volume-Number: Volume 8, Number 12