=?iso-8859-2?Q?Martin_MOKREJ=A9?= <mmokrejs(_at_)natur(_dot_)cuni(_dot_)cz>
writes:
I'd like to suggest that maybe the locking testing program which is run
before one actually compiles procmail binary, could do same trick - try to
fork and see if child sees the original lock.
procmail's locktst program doesn't test the behavior of locking across
forks, because procmail never holds a kernel lock across a fork. It only
holds kernel locks while writing to a mailbox.
I'd like to know your opinions on this topic and if there're any
consequences for promcail, which on our system is:
None that I can think of. This appears to have merely been a bug in
the configuration of your sendmail binary that Smartlist tickled when
it forced a queue run.
Philip Guenther
Procmail Maintainer
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail