home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / unix / xenix / sco / 2832 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.4 KB  |  55 lines

  1. Newsgroups: comp.unix.xenix.sco
  2. Path: sparky!uunet!cs.utexas.edu!chinacat!chip
  3. From: chip@chinacat.unicom.com (Chip Rosenthal)
  4. Subject: Re: '/etc/wtmp' how to control it's size
  5. Organization: Unicom Systems Development, Austin, TX
  6. Date: Sat, 05 Sep 1992 23:06:57 GMT
  7. Message-ID: <1992Sep05.230657.7071@chinacat.unicom.com>
  8. References: <BtyEyJ.HrE@hsi.com> <1992Sep5.013608.21192@bilver.uucp>
  9. Lines: 44
  10.  
  11. In article <1992Sep5.013608.21192@bilver.uucp>
  12.     bill@bilver.uucp (Bill Vermillion) writes:
  13. >Don't mv /etc/wtmp to /etc/owtmp because the file is opened for writing
  14. >and you will be writing to the old file.
  15.  
  16. I do not think this is an issue.  The wtmp file is only opened briefly
  17. at the time getty, init, etc. need to log an event.  So, yes, you
  18. introduce a brief subsecond race condition.  However, I can't see
  19. where that would cause any problem unless you are doing some sort of
  20. multi-pass processing of the old wtmp file and there happens to be a
  21. blue moon out this evening.
  22.  
  23. Further, if you are doing some sort of major processing of the wtmp
  24. file, there is an even bigger problem to this scheme.  By blindly
  25. copying and emptying the wtmp file, you will have wiped out the login
  26. information for current sessions.  That means that tomorrow night when
  27. you generate your reports you won't have any login records for all
  28. the people who were on the system at the time last night's cleanup
  29. was run.  That's a more significant problem.
  30.  
  31. In theory the right way to handle wtmp file cleaning is to prune out
  32. everything but the few records for the active sessions.  This is much
  33. more complicated to do, and I've yet to run into a situation where I
  34. really needed it.  Further, this is extremely difficult (if not
  35. impossible) to do without introducing race conditions.
  36.  
  37. So either you aren't doing any fancy processing and the race introduced
  38. by the `mv' is not a problem, or you are doing fancy processing and
  39. in which case there are bigger problems than this one to deal with.
  40.  
  41. With all that said and done, I pretty much do as Bill suggested.
  42. I think the best scheme would be something along the following:
  43.  
  44.     >/etc/nwtmp
  45.     chmod 644 /etc/nwtmp
  46.     chown bin /etc/nwtmp
  47.     chgrp bin /etc/nwtmp
  48.     mv /etc/wtmp /etc/owtmp        # race condition opened here
  49.     mv /etc/nwtmp /etc/wtmp        # race condition closed here
  50.  
  51. -- 
  52. Chip Rosenthal  512-482-8260 | The secret to a long life is
  53. Unicom Systems Development   | knowing when it's time to go.
  54. <chip@chinacat.Unicom.COM>   |  - Michelle Shocked
  55.