home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / mail / sendmail / 2731 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  2.9 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!netsys!agate!ames!haven.umd.edu!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!news.Brown.EDU!noc.near.net!seqp4!ajm
  2. From: ajm@seqp4.sequoia.com (A.J.Madison)
  3. Newsgroups: comp.mail.sendmail
  4. Subject: file locking after forks in sendmail 5.65
  5. Keywords: locking files in 5.65
  6. Message-ID: <1666@seqp4.sequoia.com>
  7. Date: 11 Nov 92 23:10:12 GMT
  8. Organization: Sequoia Systems Inc., Marlboro, Mass.
  9. Lines: 46
  10.  
  11. I ran into a problem of recipients complaining of receiving 2 copies of the
  12. same mail.  Careful examination of the headers and the syslogs led me to
  13. conclude that if a user had the misfortune of sending mail at the very
  14. instant the system's sendmail daemon woke up to check the queue, the mail
  15. would end up getting delivered twice.
  16.  
  17. After reproducing the problem on a test machine, I realized that locking on
  18. queue files in the spool directory was not working on our system.  We're
  19. SVR3.2 on the outside and fault tolerant & proprietary on the inside (which
  20. leaves the possibility the OS folks blew it).
  21.  
  22. Further testing showed me that the reason that locking was not working was
  23. because during the delivery phase, sendmail locks the queue file, builds all
  24. the other things it needs to - like the body of the message, forks, closes
  25. the queue file and exits, leaving the child to complete final delivery.
  26. After the fork, the queue file is wide open to any process that wishes to
  27. lock it again, including the child.  Reading the SVR3.2 manual page on fork,
  28. it explicitly states:
  29.  
  30.  The child process differs from the parent process in the
  31.  following ways:
  32.       ...
  33.    Process locks, text locks and data locks are not
  34.    inherited by the child [see plock(2)].
  35.       ...
  36.  
  37. By adding code to have the child (actually its the child of the child)
  38. re-lock the queue file, the locking is mostly preserved.  If the child cannot
  39. lock the file, the daemon must have got there first.  In any case, the files
  40. are in the spool directory, where they'll get sent eventually, hopefully.
  41.  
  42. Has anyone else noticed this issue, especially when debugging a problem,
  43. and dealt with it?  How about the BSD (and their ilk) folks.  I don't have
  44. a fork manual page from a BSD system handy (probably should...) so I can
  45. only guess that BSD systems hand down file locks to children, which could
  46. be a real mess if both parent & child choose to write to the same file.  
  47.  
  48. I'm especially cursious what other bugs may be lurking in a sendmail ported
  49. V.3 or V.4, either becaues of this issue about locking across System V
  50. forks or anything else.  (For instance I'm still not sure how much frozen
  51. configs are going to be tolerated by shared libraries.)
  52. -- 
  53. when everyone is out to get you, being paranoid is just good thinking.
  54.          - Dr. Johnny Fever <in other words, standard disclaimer>
  55. A.J. Madison                                           ajm@sequoia.com
  56. Sequoia Systems Inc.
  57.