Roderick Schertler <roderick(_at_)argon(_dot_)org> writes:
On Fri, 18 Apr 1997 16:40:31 -0500, Philip Guenther
<guenther(_at_)gac(_dot_)edu> said:
...
Without those privileges, procmail can't create the lockfile, so it
skips it.
This isn't the (only) cause here, though. I created a ~/.procmailrc
which contains just
LOGFILE = procmail.log
VERBOSE = on
I invoked it as "./procmail < message" and I got the same results:
procmail: [12334] Fri Apr 18 18:12:31 1997
procmail: Bypassed locking "/var/mail/roderick.lock"
[...]
The code in lockit() doesn't try to create the system lock file if
accspooldir isn't true, but accspooldir is only true if you use a world
writable spool dir. Either I'm missing something, or nobody who uses
procmail uses a mode 775 group mail spool dir, or people who do don't
deliver mail to their system mail box, or they're loosing mail because
their MUAs and procmail aren't agreeing on the locking which is going on
and they just don't realize it. procmail has such a great reputation
that I think I must just be missing something, but I haven't been able
to spot what.
After staring at it and running it under gdb to make sure, I'll agree
that with a 755 spool dir, procmail fails to use it group mail
privileges to create a lockfile, if, but only if, you have kernel
locking methods compiled in. Procmail will instead use them, and thus
mailboxes may still avoid corruption that way. However you got me why
procmail doesn't take a stab at setgid'ing and attempting the lock.
You'll have to ask Stephen.
Philip Guenther