Independent lockfile package.
One way or another I'd like to have a package that provides the
functionality of liblockfile on the command line, and I'd like the
package to be dynamically linked against liblockfile (so changes in
Debian locking policy remain centralized).
I know about the lockfile program in procmail, but I don't want to
require that people install procmail just to have access to a set of
command line locking programs. As an alternative to the solution I'm
proposing below, perhaps lockfile could be split out as a separate
binary package, athough it's API is a little different from
liblockfile's, and it wouldn't be dynamically linked.
In any case, I've written a tiny wrapper program that I was going to
release as liblockfile-progs. The binaries would be:
mail-lock [ -r retrycount ] [ user ]
mail-unlock [ user ]
mail-touchlock [ user ]
lockfile-create [ -r retrycount ] [ file ]
lockfile-remove [ file ]
lockfile-touch [ file ]
You would use these to write scripts like the one below (note that
lockfile-touch is launched as a separate process with responsibility
for keeping the lockfile from going stale -- it just sleeps most of
the time, but wakes up to touch the lock every so often until you kill
it):
set +e
echo "Frobnicating mailbox..."
mail-lock rlb
if [ $? != 0 ]
then
echo "Failed to lock mailbox for frobnication."
exit 1
fi
mail-touchlock rlb &
MAIL_LOCK_FONDLER="$!"
frobnicate-mailbox rlb
kill "${MAIL_FONDLER}" && true
mail-unlock rlb
if [ $? != 0 ]
then
echo "Failed to unlock mailbox after frobnication"
exit 1
fi
As a nit, I think mailunlock(3) and touchlock(3) should have taken a
"char *user" argument since maillock(3) does. You might want to lock
a mailbox from one process, and unlock it from another. I can get
around this by implementing everything in terms of lockfile_remove,
etc, but it would be nice to use the functions designed for the
purpose. Though I suspect there's probably some historical precedent
to respect.
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
Reply to: