-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Noyes wrote: > On Thu, 2006-03-30 at 04:41, Charles Steinkuehler wrote: >> Mike Noyes wrote: >> > Ugh! They went on for quite a while on that thread. I'm not sure what >> > discussed method was finally used.. >> > >> > http://moongroup.com/pipermail/shell.scripting/2005-February/thread.html#9396 >> >> The reason they're not just using the -l switch to lockfile is the >> person who started the thread is wanting to do something different in >> the script if a stale lockfile is found: >> http://moongroup.com/pipermail/shell.scripting/2005-February/009410.html > > Charles, > Thanks for explaining. :-) > >> If you're concerned about this, we'd need to jump through the same hoops >> they're mentioning in the thread. Personally, I think one of the two >> "easy" options would work for us: > > I think my exposure to the SF staff has made me overly concerned with > stale locks. They spend a considerable amount of time attending to cvs > stale locks.
NOTE: A cvs lock is *NOT* a lockfile. It is a lock placed on file(s) in the CVS repository by a that can only be removed by someone with full access to the CVS repository (ie: SF Staff). A lockfile as used by your shell script is just a normal file in our SF project space, removable by anyone with rights to delete the file (should at least be any project admins, and could safely be any project developer, IMHO). Normal *nix file permission rules apply, and no SF staff intervention is required if something goes wrong. <snip> >>From what I understand of the -l switch, it will grab the lock file if > it's older than the specified time. It does appear to take a few seconds > for this to occur though. Not a big concern in a cron script. > > Note: I'll need to shorten the -l time for my test runs. :) > Charles, > Would 'trap', as shown in the link below, achieve the results I was > looking for originally? > > Writing Robust Bash Shell Scripts: Setting traps > http://www.davidpashley.com/articles/writing-robust-shell-scripts.html Yes, using the exit trap would be a good way to clear the lockfile if something unexpected happens. The example trap commands they provide look good to me. Note instead of using bash to test for and create the lockfile, the lockfile command does both, so you could do: if lockfile -l 72000 "$LOCKFILE" ; then trap ... critical-section ... (ie: no 'touch' to create the lockfile, and no file exists check in the if statement). > BTW, I'm not using 'set -e' either. You could add this, if you want, might be a good idea. You'd have to change the places you're checking return codes: from: lockfile -r 0 -l 72000 $LOCKFILE check_errors $? "Lockfile creation failed." to: lockfile -r 0 -l 72000 $LOCKFILE || \ check_errors $? "Lockfile creation failed." Note that now the check_errors only gets called if there is actually an error (due to the ||) instead of all the time. - -- Charles Steinkuehler [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFELFILLywbqEHdNFwRAtAIAKD/J/IBtTF3Mg1swTDrtRz+WoLwuACePPCW K/JSDuVStJO7ys9T466z0nc= =9UHw -----END PGP SIGNATURE----- ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
