home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / shell / 3191 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.3 KB  |  62 lines
  1. Newsgroups: comp.unix.shell
  2. Path: sparky!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!news.acns.nwu.edu!nucsrl!ddsw1!dattier
  3. From: dattier@ddsw1.mcs.com (David W. Tamkin)
  4. Subject: stale lock removal
  5. Message-ID: <1992Jul29.161417.2473@ddsw1.mcs.com>
  6. Organization: Contributor Account at ddsw1, Chicago, Illinois  60657
  7. Date: Wed, 29 Jul 1992 16:14:17 GMT
  8. X-Disclaimer:  Material posted in this article is the sole responsibility of
  9.                 the poster and does not represent MCSNet or the system owners.
  10. Lines: 50
  11.  
  12. The discussion of file locking from the shell has raised a question in my
  13. mind.
  14.  
  15. Say a process finds that another process has the lock and it's going to wait
  16. a bit and then try again.  How can it determine whether the process that has
  17. the lock is actively using it or has stalled?
  18.  
  19. One thing I considered is to make the lock with mkdir and then > $lockdir/$$
  20. to put the locking process's signature on it.  Then, if a process finds a
  21. lock in existence, it can ps -p `(cd $lockdir; echo *)`, but [1] a stalled
  22. process might not necessarily disappear from the ps output, and [2] the
  23. process that had the lock when mkdir failed could have given it up since.
  24. Maybe [2] isn't a problem, because then ps -p would still return a nonzero
  25. exit status.
  26.  
  27. Potentially process A could find that process B had the lock and go into these
  28. tests; B could end and process C could get the lock but not yet have created
  29. the signature file by the time A tests for a signature file to find out which
  30. process has the lock.  Then, for absence of a signature file, A would get a
  31. nonzero exit from ps -p, think B had gone zombie, steal a lock that really
  32. belongs to process C, and make a mess.  [As I muse, I see some relief to that
  33. if a process giving up its lock does rm -r $lockdir so that the directory and
  34. the signature file disappear together; that way an empty lock directory could
  35. be recognized as one where a fresh lock hasn't been signed yet.]
  36.  
  37. Another thought I had was mkdir lockdir.* and then mv lockdir.* lockdir.$$;
  38. if another process has the lock, sh will expand the asterisk in the mkdir
  39. command to the existing name and mkdir will fail, even if the process that
  40. has the lock hasn't yet renamed it (in which case the asterisk will be
  41. expanded to a literal asterisk).  Unfortunately, in sh another fork will be
  42. needed (expr or tr, for example) to get the owning process out of the lock
  43. name.
  44.  
  45. I don't want an unremoved stale lock to make another process to keep
  46. repeating its sleeps until the system goes down.  One could put a numeric
  47. limit on the number of sleep cycles it takes and then, if the signature
  48. hasn't changed, figure the older process has stalled and then steal the lock.
  49. That does allow for a race condition, though.
  50.  
  51. Finally, is there some good way simply to tell the age of a lock (if not one
  52. made with /etc/link, at least one make with mknod p or with mkdir)?  If a
  53. lock is older than a certain age, one can figure that it is stale.  Various
  54. ls options will display last inode modification time or access time, but how
  55. does one compare them to the current time efficiently?
  56.  
  57. Any suggestions?  This will have to be done with shell scripts or existing
  58. utilities.
  59.  
  60. David W. Tamkin   Box 59297   Northtown Station, Illinois  60659-0297
  61. dattier@ddsw1.mcs.com    CompuServe: 73720,1570    MCI Mail: 426-1818
  62.