Jeff Orrok <jeff(_at_)rt(_dot_)com> wrote:
Ah, the joys of sheer stupidity.
I don't necessarily succeed, but I try not to go around calling things
stupid unless I'm pretty sure who's on top, me or it.
LOCKSLEEP is 8 seconds, and apparantly procmail calls lockfile with the
number of tries set to 8, so 8 seconds times (8 tries minus one try with
no leading sleep) gives 56 seconds, which is why 8 messages took almost
8 minutes to be processed.
The lockfile program is not involved. This all takes place internally
to procmail. This is normal. Procmail puts no load on the CPU during
its sleeps. Delaying is a simple and inexpensive way to let something
good happen. Eight seconds, or eighty, is a reasonable hop time, so I
don't see what's wrong with the same amount of time, for the delivery.
[lockfile] allows that failure to affect its data space as indicated by
the following samples of output:
procmail: Locking "MAILDIR/default.lock"
procmail: Error while writing to "MAILDIR/_VdH+_2Wi-.nixon.xkey.com"
procmail: Locking "MAILDIR/default.lock"
procmail: Error while writing to "MAILDIR/_VdH%_2Wi-.nixon.xkey.com"
Procmail's internal lockit() function (not lockfile) creates a temp in
its usual safe way, and renames this temp to be the desired lock-file.
The tempfile couldn't be created, so lockit() waits locksleep seconds,
and tries again, for a total of nfsTRY (eight) times. The unique-name
generator intentionally rotates one character of the filename from one
try to the next, in hopes of finding an empty slot in the hash bucket.
The observed behavior was not the result of any inadvertent data space
corruption, nor is it a design flaw.
Mike
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail