Hi, thanks for answering!
Philip Guenther writes:
Adriano Nagelschmidt Rodrigues <anr(_at_)ime(_dot_)usp(_dot_)br> writes:
Mail is being delivered over NFS on a machine running SunOS 4.1.3_U1, the
procmail version is:
procmail v3.11pre7
Locking strategies: dotlocking, fcntl(), lockf(), flock()
It's my recall that you SunOS 4.x doesn't let you lock a file with all
of those at the same time.
But doesn't procmail use only one of the locking methods above, let's say the
first (right to left) that works?
That implies that you overrode the output of the procmail autoconfiguration
with regards to which locking methods to use. Don't do that.
I did nothing of the sort ;-) Seriously, I compiled procmail on the machine it
is being used and let it choose the locking methods it thought fit.
The only change I made was setting the default user mailbox to $HOME/Mailbox
rather than /var/spool/mail/user.
Go into the source, do a "make realclean",
then make sure that LOCKINGTEST is *NOT* defined in the Makefile, and
then run "make" and give the resulting binary a try. About the only
reason you should override the autoconf process is to turn *off*
locking methods that you know don't work; e.g. if you use mailtool then
you have to turn off all kernel locking methods as mailtool is broken.
Hmm, selecting locking methods might be a good idea. If I suspect that there
are some problems with NFS interaction between SunOS 4.1.3 and Solaris 2.5.1,
which locking methods should I discard? Maybe kernel locking is the best
candidate to leave...
Best regards,
--
Adriano