I wrote in response to Matt Garretson's question about locking the logfile,
| > Procmail usually gets along without locking the logfile. Writes to it are
| > short (in comparison to what gets written to a folder) and usually a lock
| > is not needed.
James McGill responded,
| Yikes! Is that really the criteria you use to decide if locking is needed?!
No; it is the criterion Stephen used. I'm just a procmail user, Mr. McGill.
In fact, I'm one of the people who has questioned him about it. He felt, as
I recall, that locking the logfile wasn't worth the extra CPU effort;
moreover, it would usually have the same effect as a single global lockfile
because most procmail users keep only one logfile for all their incoming
email, so locking the logfile would force the effect of a single global
lockfile.
| In some places you would be flogged!
If they would flog me instead of Stephen for it, then they should be subject
to trade and communications sanctions for human rights violations.
| Is it *possible* for two instances of a process to open a file for writing
| at the same time?
Absolutely. It happens in my logfile all the time, especially when procmail
spins off clones. If you regularly use verbose logging on incoming mail (as
contrasted to mail you reprocess interactively, which, unless you use
formail's -ns option instead of -s, will process its input one message at a
time anyway), you'll run into such interleaving of log entries even without
any cloning in your .procmailrc.
| Then it is *necessary* to take measures to prevent this.
That depends on the importance of the integrity and legibility of your
logfile. I consider it less than the importance of the legibility and
integrity of my mail folders, and I live with the interleaving.
| Then it is *necessary* to take measures to prevent this.
And in my response to Mr. Garretson I explained the measure that can be
taken: a global lockfile that allows only one procmail instantiation per user
to run at a time. Unless users share logfiles, that would solve the problem.
You can, if you like, lock that global lockfile immediately before any action
that would be logged and unlock it just after; that would slow procmail down
less than if the global lockfile were in effect from start to finish.