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.
procmail mailing list