From: Philip Guenther <guenther(_at_)gac(_dot_)edu>
Michael J Wise <mjwise(_at_)kapu(_dot_)net> writes:
<description of kludge to atomicly add entries to the procmail log>
...
We'd like something a bit more economical in terms of processor
performance, as we are trying to run some scripts based on the logfiles
to report the 'Performance' of our SpamTraps.
What are you extracting from the logs that you need to guarantee to
be uninterwoven? Procmail line buffers the logs**, so unless you are
matching up items logged on different lines, you don't really need
atomic writes.
I'm not enough of a programmer to understand that fully, but I
will say that I've seen corrupted logs before. I, too, have over
the last ten days or so been building a procmail-based mail
management system that relies heavily on custom messages in logs
for traffic analysis.
Wondering if Michael might want to send data piecmeal to his
data parser at the same time that he shunts it to the log. Perhaps
`tee' can be useful here.
I guess we could write a little script that calls lockfile, and then
appends the result, and then tosses the lock, or just put the various
logfiles into their own directory, and date 'em (log.1027659003.1234),
ec. etc. etc., but ... it would be even spiffier if ProcMail had some
sort of facility that made this automatic instead of a Kludge, However
Elegant[tm].
This is more complicated an issue than it may appear at first glance.
Actually locking the log with a kernel lock may create a denial of
service attack if the log is world readable***.
I don't see this quite, either. I am trying to lock the log for
a couple of seconds nightly when I switch logs. It seems not to be
working, though, as my lockfile sticks around despite the `rm -f'
command.
--
dman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail