"James L. McGill" <fishbowl(_at_)fotd(_dot_)netcomi(_dot_)com> writes:
On Thu, 2 Jan 1997, David W. Tamkin wrote:
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.
Yikes! Is that really the criteria you use to decide if locking is needed?!
In some places you would be flogged! Is it *possible* for two instances
of a process to open a file for writing at the same time? Then it is
*necessary*
to take measures to prevent this.
No, it is only necessary if interleaved messages are an error.
Procmail open the logfile with O_WRONLY|O_APPEND|O_CREAT, so it's the
OS's responsibility to not _lose_ written data (the O_APPEND will do
that). If you want to avoid interleaved messages that you will either
need to impose a locking protocol on top of the logfile, or not use the
logfile for the purpose you're putting it to.
More importantly, locking the logfile leads to all sorts of really ugly
conditions: where do you report a locking error on the LOGFILE?
Breaking the lock defeats its purpose, and neither /dev/console nor the
original stderr are useful alternatives.
In my view, the LOGFILE has two main uses: reporting errors, and
providing a tracelog of procmail actions. The former will most likely
be 'parsed' by a human, while the latter usually doesn't qualify as a
critical activity. If it does, create your own log and turn
LOGABSTRACT off.
Philip Guenther