On 9 Mar 2005 at 10:46, Eric Thomas wrote:

> No. LISTSERV checks the number of lines in the digest every time it
> processes a new posting. There is no internal counter that could have
> gotten corrupted.

I don't know much about the internal processes of Listserv, but this 
doesn't fit our observations. What we are seeing is the digest build 
toward the specified size (currently 1000 lines). In the majority of 
times that it reaches the 1000 line limit (plus whatever number of 
lines over the limit the last note puts the digest), we are seeing 
two events reported in listserv.log:

-> RSET
421 Error: timeout exceeded

And the digest is **not** sent out. We see this behavior repeat 
itself when the digest reaches every multiple of 1000 lines. Most 
often, the digest then fires at the specified time of the regular 
digest. (In between regular digests, it is not uncommon for our 
digest to reach over 6000 lines, which is far bigger than most of our 
subscribers would prefer.)

If what you are saying is correct, then I have to assume that every 
time a new message comes in after the digest reaches the 1000 line 
limit, Listserv will attempt to send off the digest. If that is 
happening, Listserv is failing every time in these circumstances, 
which amounts to somewhere in the vicinity of 50-75 times per day.

So, if Listserv doesn't have an internal counter, is the process that 
Listserv receives a new message, delivers it the SMTP, then adds it 
to the digest, then counts the lines in the digest? If so, does 
Listserv do that using an internally defined function, or using a 
*nix command (we're on a *nix system) such as wc?

> Your log shows that LISTSERV is sending the digest.

No, the log doesn't show Listserv sending the digest when it is 
supposed to. We have observed in real time the digest and 
listserv.log as the digest builds towards the 1000 line limit. And we 
have observed the logging of listserv processing the mail which puts 
the digest over the 1000 line limit. There is no record in the log 
that at this point Listserv even attempts to send out the digest.

>  The 421 error you
> are seeing comes from the SMTP workers and should be addressed, but is
> unrelated. LISTSERV is happy as long as it is able to queue the mail
> for later delivery. 

And what happens if listserv decides to send the digest, but fails in 
queueing the mail for later delivery?

> The SMTP workers are separate processes that work
> asynchronously from the main LISTSERV process and report any errors to
> the log as they occur, but do not feed any information back to
> LISTSERV. In a nutshell, the digest process doesn't even know what
> problems the SMTP workers may be encountering.
> 
> Your log suggests that the digest is sent successfully (forgetting the
> 421 error), but is then not reset. 

Again, no the log shows no attempt to send the digest when it reaches 
the line count limit.

> This can only happen if some kind
> of error occurs in the digest posting process. I vaguely remember that
> in an earlier version, I think it was 1.8c but it could have been
> 1.8d, there was a condition where some types of errors in digest
> processing were not reported to the log, so it may have looked like
> everything was ok, but in fact an error did occur. If you have other
> lists, you will want to check if their digests are working correctly.

Every other list sends off correctly. 

> Either way, you should take a close look at digests.file and eyeball
> listname.digest for anomalies. Sorry but I can't do much more about a
> problem with 1.8d.

We have looked at the digest files every which way we can think of, 
using several suggestions from this list, to no avail. We can find no 
digest anomolies in the one digest that cause any of the other 
digests to choke. That is one of the reasons we're stumped.

Doug