home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v8 / text0011.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  4.1 KB
  1. From: pyramid!nsc!hplabs!hpda!hpisoa1!davel (Dave Lennert)
  2. Date: Wed, 29 Oct 86 10:07:47 -0800
  3.  
  4. > From: seismo!munnari!yabbie.rmit.oz!rcodi@sally.utexas.edu (Ian Donaldson)
  5. > Date: Tue, 21 Oct 86 10:39:40 EST
  6. > 
  7. > What is the significance of the "saved process group ID"?  How is
  8. > it different to the normal process-group-ID?  Who uses it?
  9.  
  10. The saved process group ID is analogous to the saved user and group ID's
  11. in System V.  They preserve the original values the process had when
  12. exec'd.  This allows the process to adopt a different value for one
  13. of these ID's and later return to its original value.  Without a "saved"
  14. value, all knowledge of the original value and of the process's rights
  15. to use it are lost.
  16.  
  17. The saved process group ID value is necessary with job control in the
  18. following scenario:
  19.  
  20. Root user su's to non-root user whose login shell is a job control shell
  21. (say csh).  Csh resets its process group to a new value (it becomes a
  22. process group leader).  When it terminates or suspends, it needs to
  23. restore both the tty group ID (a process group ID value) and its own
  24. process group ID back to the original values they had at entry.  (This
  25. restores its parent to the foreground.)  Under 4.2 this is no problem
  26. since there are no security checks for this.  Under POSIX there are
  27. security checks based on uid's which normally are allowed since the uid of
  28. the parent process and the csh are identical, but in our scenario would
  29. be disallowed because the uid's don't match.  The saved process group ID
  30. is an alternate security check which allows the above scenario.  See the
  31. security discussion in setpgrp2() and in the POSIX termios proposal.
  32.  
  33. > >          If    the process is a session process group leader, the
  34. > >          SIGHUP signal may be sent to each process that has    a
  35. >                ^^^ should be replaced by the word "will"
  36. > >          process group ID equal to that of the calling process;
  37.  
  38. "May" is used here to allow 4.2 systems to conform.  4.2 does not
  39. send SIGHUP on process group leader death.
  40.  
  41. Note that, with a job control shell, all child processes started by
  42. the shell are placed in a different process group than the (process
  43. group leader) shell is in.  Thus when the shell dies, SIGHUP is not
  44. seen by any of the children anyway.
  45.  
  46. > I disagree with the proposal on the handling of _exit processing for
  47. > job control.  It should be possible to not have to know in advance
  48. > that you wish to log-off and leave something running that you started
  49. > in foreground and later shifted to background.  This is a KEY feature
  50. > of job control.  
  51.  
  52. This key feature is preserved in the POSIX specification.  Perhaps I
  53. don't understand your statement.
  54.  
  55. > vhangup() will provide clean terminals on a bsd system,
  56. > and we have improved vhangup further to not just turn off READ/WRITE bits,
  57. > but to actually redirect the file references to /dev/null (which has
  58. > the advantage of also dropping DTR reliably). 
  59. > I see no mention of a vhangup equivalent in this proposal segment, but
  60. > then again, I haven't seen the whole of P1003 either.
  61.  
  62. vhangup() is indeed desirable.  It is not required in POSIX because it is 
  63. not supported on System V and, indeed, breaks System V compatiblity.
  64. (See my job control paper that was posted in mod.std.unix recently.)
  65.  
  66. > Children of init that are stopped are also sent SIGHUP's and SIGCONT's.
  67.  
  68. More correctly, at the time a stopped process is inherited by init (due 
  69. to its parent's death), it is sent SIGHUP and SIGCONT.  POSIX has this
  70. too; see the _exit part of the job control specification.
  71.  
  72. > Infinite-loop processes don't cause problems with system-response because
  73. > they are automatically niced (something that is long-needed in UNIX systems).
  74.  
  75. Note that this is NOT desirable on, e.g., realtime systems where that
  76. long running process may be critical.  I'm also getting tired of having
  77. my rwhod reniced automatically.
  78.  
  79.     Dave Lennert                ucbvax!hpda!davel               [UUCP]
  80.     Hewlett-Packard - 47UX      ihnp4!hplabs!hpda!davel         [UUCP]
  81.     19447 Pruneridge Ave.       hpda!davel@ucb-vax.ARPA         [ARPA]
  82.     Cupertino, CA  95014        (408) 447-6325                  [AT&T]
  83.  
  84.  
  85. Volume-Number: Volume 8, Number 12
  86.  
  87.