Hello all,
I have a locking problem here which I am somewhat unsure about myself.
System: solaris 2.5, $HOME is local disk, /tmp is local, system mail file
is NFS mounted from a sunos 4.1.3 machine onto the local solaris machine.
For compiling procmail on solaris, I specified /tmp, $HOME, and
/var/mail/myuser for the locking tests, result:
Locking strategies: dotlocking, fcntl(), lockf()
The problem is that procmail and mailtool are deadlocking each other when
procmail is delivering to the system mailbox /var/mail/user and mailtool
has a window open. The same happens with dtmail instead of mailtool.
Everybody says mailtool is buggy. The procmail docs say to disable the
remaining 2 locking functions, which I did, so dotlocking remains.
Question: what exactly is dotlocking? I greped the docs but could not
find a clear definition. Is it the creation of a file.lock file? If so,
I don't think mailtool bothers to create some such and I see no way to
make it do so, which means I am living very dangerously.
The deadlocking (i.e. waiting for each other forever) does not occur
when I get rid of the system mailbox and always deliver to a file under
$HOME at the end of .procmailrc, but I don't want to shift my incoming
mail into my account for space reasons (or anyone can bomb me out by
filling my quota).
(On the side, with procmail 3.10 at least the docs say falling off the
end of .procmailrc delivers to $DEFAULT which defaults to the system
mailbox. This is not true. procmail ALWAYS delivers to /var/mail/user
when falling off .procmailrc, REGARDLESS of the setting of $DEFAULT. I
did not test the behaviour of 3.11pre7.)
Does anyone know how to make this setup safe? As an added bonus(?),
the mail is actually delivered on that sunos 4.1.3 machine. Currently I
am just doing a "rsh solaris ~/bin/procmail" in .forward to not have to
process mail on that extremely limited sunos box. Btw running procmail
on the sunos machine instead of the solaris machine does not prevent
the deadlocking.
Any hints appreciated. Thanks
Volker