procmail
[Top] [All Lists]

Re: "Atomic" updates to the LOGFILE...

2002-07-26 00:51:20
Philip Guenther wrote:
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, ...

Bingo.

you don't really need atomic writes.

We're generating a report based on the information included in the
logfiles. Here's an example of what is in them now:

        ^
        From: webmaster(_at_)rendezvoususa(_dot_)com
        X-Input:  66.171.52.96
        Comments: PaleOpala_Gold: To: has no immediately following whitespace
        Comments: PaleOpala_Gold: Faux-LavaNet; mxN is a virtual server
        Comments: PaleOpala_Gold: Content-Type: Faux-Outlook
        Comments: PaleOpala: Message-Id: assigned locally (MX1).
        >From system Thu Jul 25 13:45:17 2002
         Subject: Don't stay alone!
          Folder: Trash/Gold/msg.iO6E                                           
   2148
        ^

We're doing stats on the emitted Comments: lines based on the fact that
the email was stored into the Trash, plus reporting the From: and
Subject: lines in sorted order. Now, imagine what would happen if two
pieces of email, one Spammish and the other legit, arrived at the same
time? It happens, and so to keep the log report sane, we went to atomic
writes as described previously.

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***.

It won't be, and most likely the home directory would be go-rx. But still,
we'd rather not lock the logfile either way.

Can you explicitly (extract and) log the data you need for you analysis
in a single line?  If so, that should provide all the guarantee you need.

I like my logs human-readable. But I suppose we could. It would be nice if
it wasn't an issue, but that each invocation of ProcMail could buffer its
stuff until the end of the program, and write it then in one atomic act.

Aloha mai Nai`a!
-- 
"Please have your Internet License             http://kapu.net/~mjwise/
  and Usenet Registration handy..."

_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail