--On Wednesday, July 13, 2011 10:16:12 AM -0700 Kenneth Porter shiva@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