--On Wednesday, July 13, 2011 10:16:12 AM -0700 Kenneth Porter
<shiva@xxxxxxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
