My, it's been many a moon since I last had a procmailrc problem :) My ISP
added a new machine recently an decided to move some of the users onto the
new one. I had to unsub from all mailing lists and resub because of a
slight change in email address. A few things have been going wrong since
then, but just tonight I noticed that nearly every entry in my procmail log
contains the warning:
procmail: Lock failure on "/var/spool/mail/eristic.lock"
(No need to say I haven't changed anything in the procmailrc... for months.
Never got this behavior before)
All mail seems to be delivered correctly (if I've lost any, I wouldn't know
anyway) but if procmail can't put a lock on the output file, what's to
protect the mail folder from being clobbered? I have never specified a
"custom" lock file in the procmailrc; procmail was always able to figure
the default bits correctly - what could be preventing this now? If the path
is no longer /var/spool/mail/, why wouldn't procmail know the proper new
path?
Anyway, I looked up the docs, and sure enough, the manual says
Lock failure on "x" Can only occur if you specify some
real weird (and illegal) lock-
filenames or if the lockfile could
not be created because of insuffi-
cient permissions or nonexistent sub-
directories.
I suspect it is the latter - permissions problem. The directory itself
*must* exist since mail gets delivered to $DEFAULT properly, after all. I
then pull up the FAQ, read, and talk to myself (and now the list):
17. I sometimes get these `Lock failure on "/usr/mail/$LOGNAME.lock"'
errors from procmail. What do I do about it?
<snip>
There are several solutions to this problem:
Some systems support the sticky bit on directories (when set only
allows the owner of a file in that directory to rename or remove it).
This enables you to make /usr/spool/mail drwxrwxrwt. It is thus
effectively world writable, but all the mailboxes in it are protected
because only the mailbox owner can remove or rename it.
-> Nah, I don't suppose it's in my power to change permissions that way :)
If your system did not exhibit the !(_at_)#$%^&* POSIX semantics for
setgid(), procmail would have been able to switch back and forth
between group mail and the group the recipient belongs to without
creating security holes.
If your system supported setrgid() or setregid() or setresgid() with
BSD semantics, procmail would have been able to switch... (see the
previous point).
-> Even if the above didn't go right over my head, I'd still have to talk
to the admin...
You could simply put the following at the end of your .procmailrc file:
LOCKFILE # removes any preexisting lockfile
LOG=`lockfile $DEFAULT$LOCKEXT`
TRAP="rm -f $DEFAULT$LOCKEXT"
:0
$DEFAULT
-> This looks like Just The Ticket, but... why at end of the procmailrc?
Some of my rules explicitly file mail in $DEFAULT just so the mail won't
fall through to the anti-spam recipes below in the file, and also so that I
have a clear entry in the log. Will it do to just cast the above lockfile
spell on TOP of the procmailrc?
You could, instead of using /usr/mail/$LOGNAME, use a file below your
home directory as your default mailbox.
-> And tell the POP3 daemon to get my mail for me from the new location,
how?
Or, you could still use /usr/mail/$LOGNAME as the mailbox, but simply
instruct procmail to use a different lockfile. This can be achieved by
putting following recipe at the bottom of your .procmailrc file:
:0:$HOME/.lockmail
$DEFAULT
-> I get this bit, but does that mean I need to add the lockfile location
to each and every delivering recipe (that writes to a file)? Can this be
achieved globally from the level of .procmailrc?
You have to make sure that all other programs that update your system
mailbox will be using the same lockfile of course.
-> Well I do use Pine about twice a year, if that counts ;)
You can ignore the problem if you know that both your mail reader and
procmail use an overlapping kernel locking method.
-> Nearly without exception (see above) I use win95 mail clients to get
mail via POP3. I've no idea what locking strategy the POP3 daemon has,
though.
I'll appreciate any suggestions... possibly other than to call the ISP in
the morning :)
.marek
--
General Frenetics, Discorporated: http://www.lodz.pdi.net/~eristic/
"The war isn't the war between the blacks and the whites, the liberals
and the conservatives, or the Federation and the Romulans. It's between
the clueful and the clueless." (an anonymous poster on Cypherpunks list)