procmail
[Top] [All Lists]

Re: And then, suddenly... "lock failure on x" (long-ish)

1998-08-05 10:49:05
Marek Jedlinski wrote,

| ... just tonight I noticed that nearly every entry in my procmail log
| contains the warning:
| 
|  procmail: Lock failure on "/var/spool/mail/eristic.lock"

Yup ... your old setup either had a setgid procmail or a world-writable but
sticky mail spool directory, so it could create and remove the local lock-
file.  Your new one has neither, so it cannot.

Your spool file still belongs to you with 600 perms (or maybe 660 if it is
group "mail"), so your processed can change its contents, but you don't have
permission to add, remove, or rename any filename entries in /var/spool/mail/.

| 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?

If you had lock problems show up, it would be messages mixed together more
likely than just missing.

| If the path is no longer /var/spool/mail/, why wouldn't procmail know the
| proper new path?

If the admins changed the path and then just copied the existing procmail
binary over without recompiling it and letting the build routines reconfigure
it for the new platform, it wouldn't know the new path.  However, if your pop
client is still finding your mail without being told a new place to look for
it, then the path hasn't changed.

Marek quoted the FAQ:

|     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 :)

No, but and most admins won't listen to reason to change them; they'll leave
the permissions the way they came with the OS.

|     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...

If you compiled procmail yourself, it wouldn't apply anyway.  That is of
use only if procmail can change its effective group ID while running: in
other words, usually meaning that (1) the mail spool directory is group mail
with 775 permissions and the procmail binary is setgid mail, or (2) the
procmail binary is setuid root.

|     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?

No, don't put it up top, because then all your mail will be delivered to
$DEFAULT.

I don't see the logic in that suggestion anyway.  The whole problem is that
your processes cannot create $DEFAULT$LOCKEXT nor remove it, so it won't
solve anything.  You can move $DEFAULT to where you can create and remove a
lockfile named for it (which is the next suggestion) or change the lockfile
for $DEFAULT to a place where you can create and remove it (which is the
suggestion after next).  [Even if the lockfile binary is setgid mail, rm
is not, so you wouldn't be able to remove the lockfile after the messge is
saved nor to add another message to that folder until the lockfile was deemed
stale, usually seventeen minutes later.]

|     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?

That I do not know.  It would be the best solution, and it's what I recommend
to people who read their mail on-line at their providers if they have this
problem.  All it takes is changing the value of $DEFAULT.

|     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?

Yes, you'd need to name the local lockfile on every save to $DEFAULT, and no,
it can't properly be achieved globally.  You could do it globally by naming
$HOME/.lockmail [or whatever] as a global lockfile for your whole
.procmailrc, but then a procmail process that delivers to another folder or
doesn't deliver to a folder at all could not run at the same time as one that
delivers to $DEFAULT.

|       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 ;)

More importantly, what clears out your mailbox when you use POP3?  That's
what would have to use the same lockfile.

|       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.

There, too, I do not know.

There is one other bit of advice I can give: if you find a solution that
requires changing every recipe that saves to $DEFAULT, you might find it
easier to put the new code for saving to $DEFAULT into a separate rcfile
and to call it with INCLUDERC=filename rather than repeating the code every
time.

Good luck.

<Prev in Thread] Current Thread [Next in Thread>