Re: Apparent bug in logwatch's reporting of number of email by sendmail

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]





--------------------- sendmail Begin ------------------------

 STATISTICS
 ----------

 Bytes Transferred:      5241
 Messages Processed:     2
 Addressed Recipients:   2

 ---------------------- sendmail End -------------------------

I'd also like to know where/how logwatch is getting the number for
"Bytes Transferred"; it doesn't seem to correspond to anything.

So, unless I'm missing something, that's two problems.  Does anyone
see any others...?  or have a plausible explanation for these
inconsistencies?

tia.

Ken, the bytes transferred looks to be the size of the first two log
entries (2485 + 2756 = 5241). I'm not sure what logwatch considers
individual messages in its sendmail stats, but a unique message ID does
indicate a unique message. I also want to point out that if your
logwatch is generating an email, this may be counted in the stats also
(how, I'm not sure). If logwatch is running at 4AM, when these emails
are being sent, I could also anticipate some problems, depending on the
timing involved and when log entries are committed to the log. Overall,
I wouldn't be concerned.

--Blake

My major concern is accuracy. I mean, there's not much sense in using logwatch if what it's telling me is wrong.

The fact that logwatch runs at 4am shouldn't be the problem here, as logwatch is culling data from the previous day. So no conflict there (if that's what you were implying).

You're right about the Bytes Transferred number. "size" is mentioned *three* times in maillog. It's just another curiosity how logwatch picked the two numbers that it did. However it did it, obviously it's double-counting, so logwatch is getting that number wrong as well.

Based on the day of 'Mar 12', I agree with the bytes transferred. Logwatch's sendmail component appears to be using the sendmail queue ID (vs the message ID) as an identifier for a unique message. Using this identifier, I too count 2 messages (t2C82IiB027383 and t2C82Bjr027151). Looking at recipients, I also count two: recip@dest and <recip@xxxxxxxx>.

What criteria to use as a means of identifying a unique message is certainly a choice. I can see how some would choose the MUA's message ID instead. However, that may be more error prone given that this is not guaranteed to be a unique value within a data set. Sendmail's queue ID should be unique in a day's data on a single server.

--Blake
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux