home *** CD-ROM | disk | FTP | other *** search
/ CD Actual 8 / CDACTUAL8.iso / docs / kernel-2.0 / locks.txt < prev    next >
Encoding:
Text File  |  1996-07-11  |  2.8 KB  |  65 lines
  1.               File Locking Release Notes
  2.  
  3.         Andy Walker <andy@lysaker.kvaerner.no>
  4.  
  5.                 15 May 1996
  6.  
  7.  
  8. What's New?
  9. -----------
  10.  
  11. Flock Emulation Warnings
  12. ------------------------
  13. Many people will have noticed the ugly messages that the file locking
  14. code started generating with the release of kernel version 1.3.95. The
  15. messages look something like this:
  16.  
  17.     fcntl_setlk() called by process XX with broken flock() emulation
  18.  
  19. This is a warning for people using older C libraries that those libraries
  20. are still calling the pre 1.3.x flock() emulation routines, instead of
  21. the real flock() system call. The old routines are quite badly broken,
  22. especially with respect to parent-child lock sharing, and can give bad
  23. results if, for example, sendmail attempts to use them.
  24.  
  25. Fixed versions of the C libraries have been on public release for many
  26. months. The latest versions are 5.2.18 or 5.3.12 for ELF, and I believe
  27. somebody made a 4.7.6 release for people using a.out systems.
  28.  
  29. In 1.3.96 Linus decided to be lenient on the stragglers and changed the
  30. warning message so that the kernel will only complain five times and
  31. then shut up. That should make life more bearable even for people who,
  32. for some reason, don't want to upgrade.
  33.  
  34. Sendmail Problems
  35. -----------------
  36. Because sendmail was unable to use the old flock() emulation, many sendmail
  37. installations use fcntl() instead of flock(). This is true of Slackware 3.0
  38. for example. This gave rise to some other subtle problems if sendmail was
  39. configured to rebuild the alias file. Sendmail tried to lock the aliases.dir
  40. file with fcntl() at the same time as the GDBM routines tried to lock this
  41. file with flock(). With pre 1.3.96 kernels this could result in deadlocks that,
  42. over time, or under a very heavy mail load, would eventually cause the kernel
  43. to lock solid with deadlocked processes.
  44.  
  45. Disallow Mixed Locks
  46. --------------------
  47. I have chosen the rather cruel solution of disallowing mixed locking styles
  48. on a given file at a given time. Attempts to lock a file with flock() when
  49. fcntl() locks exist, or vice versa, return with an error status of EBUSY.
  50. This seemed to be the only way to avoid all possible deadlock conditions,
  51. as flock() locks do not strictly have one owner process and so can't be
  52. checked for deadlocking in the usual manner.
  53.  
  54. The process that created a lock with flock() might have forked multiple
  55. children and exited. Previously the parent process would have been marked
  56. as the owner of the lock, but deadlocks could just have easily occurred in
  57. one or more of the children, which we would not have been able to identify
  58. and avoid.
  59.  
  60. Some programs may break (again, groan). In particular the aforementioned
  61. sendmail may have problems running in 'newaliases' mode. It will no longer
  62. deadlock though. Recompile sendmail to use flock() and your troubles will
  63. be over.
  64.  
  65.