Kristian Roenningen asked,
| I'm sorry if this question is one of the standard ones, but I've asked
| many people for help about this, but noone seems to know..
Well, yes, it is an FAQ.
| When I run pop (a script) I get, after a while, this message:
| lockfile: Try praying, giving up on "/var/spool/mail/krr.lock"
|
| This message appears ONCE for each mail I get. The mail finds its way
| to the mailspool with no trouble, it's just annoying with this error-
| message. If anyone knows what the problem might be, and how to fix it
| I would appreciate it alot.
It should appear only for each message that procmail tries to save to
/var/spool/mail/krr. This situation usually has one cause: your user ID
can cd to /var/spool/mail and can write to /var/spool/mail/krr (because that
file already exists, belongs to you, and has owner write permisson) but it
does not have permission to create or remove files in /var/spool/mail.
The sensible but naive solutions are to chmod the spool directory to 1777
(but only if your system supports sticky directories safely) or to make
procmail setuid root. Since each of those would require sysadmin coopera-
tion, they're usually out of the question.
If you live on earth and are not the system administrator yourself, you
probably can't get that kind of cooperation. So you have two basic routes
to try instead:
1. Name a lockfile for procmail's saves to default, and place that lockfile
in a directory where you can write. For example, finish your procmailrc
this way:
:0:.spool.lock
$DEFAULT
:0e:.orgmail.lock
$ORGMAIL
I'm starting the lockfile names with periods so that (1) they won't
interfere with other deliveries if for some reason you decide to name
folders "spool" or "orgmail" and (2) they won't show up if you ls your
$MAILDIR to see what folders are there.
The drawback here is that this will keep two procmails from conflicting
with one another as they deliver your mail, but your popclient probably
won't recognize these lockfiles and procmail won't recognize the popcli-
ent's locking method, so you can run into conflicts if the popclient and
procmail try to modify your spool at the same time. That can be averted
by using lockfile (the program) to lock $MAILDIR/.spool.lock before you
start the popclient and to remove that lockfile when you're done down-
loading. That way procmail will be kept out of the popclient's hair.
2. Don't use a file in /var/spool/mail as your $DEFAULT. In your
.procmailrc, set
DEFAULT=some_name_you_pick
and then your otherwise undiverted mail will be filed in
$MAILDIR/some_name_you_pick and the local lockfile for storing it there
will be $MAILDIR/some_name_you_pick.lock ("pick lock"?).
The drawback to this method is that the popclient may be too rigidly
configured for you to teach it to find your mail in $DEFAULT instead
of /var/spool/mail/$LOGNAME.