home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / unix / wizards / 4816 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.0 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek
  2. From: torek@horse.ee.lbl.gov (Chris Torek)
  3. Newsgroups: comp.unix.wizards
  4. Subject: Re: Changing the owner of a process
  5. Date: 20 Nov 1992 20:30:42 GMT
  6. Organization: Lawrence Berkeley Laboratory, Berkeley
  7. Lines: 29
  8. Message-ID: <27581@dog.ee.lbl.gov>
  9. References: <27551@dog.ee.lbl.gov> <1992Oct29.162445.23551@eng.ufl.edu> <1cpjs4INNn3@early-bird.think.com> <1992Nov5.152833.27744@dale.ksc.nasa.gov> <1992Nov17.142837.21252@dale.ksc.nasa.gov> <1992Nov19.220759.1846@exlog.com>
  10. Reply-To: torek@horse.ee.lbl.gov (Chris Torek)
  11. NNTP-Posting-Host: 128.3.112.15
  12. Keywords: process ownership
  13.  
  14. In article <1992Nov17.142837.21252@dale.ksc.nasa.gov> I noted that
  15. >>If you simply reach in and replace a process's uid, the kernel will 
  16. >>eventually panic when it notices the inconsistent counts.
  17.  
  18. In article <1992Nov19.220759.1846@exlog.com> mcdowell@exlogcorp.exlog.com
  19. (Steve McDowell) writes:
  20. >Why is it going to panic over an inconsistent process count?  That's
  21. >simply not good operating system design.
  22.  
  23. I will make you a deal:  If you do not try to tell us how to do O/S
  24. research, I will not try to tell you how to sell commercial systems.
  25.  
  26. >When it hits an inconsistancy (as it eventually will in some remote
  27. >region of the world) it should simply alert the operator and re-count
  28. >things.
  29.  
  30. If the counts are goofed up, either the hardware is broken---the 4.4BSD
  31. development line is not intended to be able to handle this situation,
  32. although if it recurs predictably we will probably hack around it---or
  33. (far more likely) there is a bug in the kernel source.  An immediate
  34. panic gives us a much better chance of finding and repairing the bug
  35. than a syslog-and-reset.
  36.  
  37. Commercial vendors are free to replace various panic()s with the
  38. appropriate recovery code.  For our purposes, recovery is not only
  39. unnecessary, it is in fact *in*appropriate.
  40. -- 
  41. In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
  42. Berkeley, CA        Domain:    torek@ee.lbl.gov
  43.