--On Wednesday, July 13, 2011 10:16:12 AM -0700 Kenneth Porter <shiva at sewingwitch.com> wrote: > I was about to ask here how to do proper locking in a bash script when I > found a page that addressed my objections to the race conditions I was > finding in most sample code: > > <http://www.davidpashley.com/articles/writing-robust-shell-scripts.html> > > I just wanted to pass on the link to anyone else that needs this. > > One thing not addressed is how to deal with an orphaned lock file (eg. if > the system crashes with the lock held). He stores the PID in the lock > file, so one could look up the matching process and see if it's the > script that's expected to create it. Otherwise one should be safe in > deleting the lock file and trying again. If you're concerned about an OS crash, you can distinguish that case by putting your lock files into either a directory that is cleaned up by the system on boot (like /var/lock) or to put it in a tmpfs filesystem (such as if you have /tmp mounted as tmpfs). If you're using the latter, then watch for other users playing silly-bugger with your lock files to try to compromise or crash your system, such as making /tmp/mylockfile a symlink to /etc/passwd so that you can trash it when you try to write to it. (See the last paragraph on avoiding it.) If you're concerned about a script crash, the trap (with 0 1 2 15) takes care of that. However, although I like the trap mechanism for dealing with cleaning up temporary files (especially those files or directories containing temporary files created by mktemp(1)), I don't think that it's the right tool for lock files. Instead, have a look at flock(1) to avoid the race conditions. (See flock(2) about its unsuitability for locks on NFS filesystems, though.) Devin