Re: [Fetchmail-users] sometime in the night, fetchmail 6.5.0beta6 heard a bump

[Matthias A. <mat...@gm...>]

Am 06.11.21 um 18:45 schrieb Gene Heskett:
> On Saturday 06 November 2021 12:44:47 Matthias Andree wrote:
>
>> Am 06.11.21 um 03:22 schrieb Gene Heskett:
>>> On Friday 05 November 2021 17:22:48 Gene Heskett wrote:
>>>> On Friday 05 November 2021 17:05:16 Matthias Andree wrote:
>>>>> Am 05.11.21 um 21:57 schrieb Gene Heskett:
>>>>>> On Friday 05 November 2021 14:14:32 Matthias Andree wrote:
>>>>>>> Am 05.11.21 um 17:52 schrieb Gene Heskett:
>>>>>>>> Greetings Mathias;
>>>>>>>>
>>>>>>>> The bump was a msg that landed in the inbox at
>>>>>>>> imap.shentel.net. no subject, no body, no from address, from
>>>>>>>> the debian listmail server. at about 6:53 EDT.
>>>>>>>>
>>>>>>>> That convinced fetchmail it had an error 7, and exited that
>>>>>>>> invocation without fetching any more msgs.  Wash, rinse and
>>>>>>>> repeat at 2 minute intervals till shentel and I figured it out
>>>>>>>> a few seconds after the log entry below.
>>>>>>>>
>>>>>>>> log looked like this:
>>>>>>>>
>>>>>>>> ov 05 11:42:32 fetchmail: 54 messages for ghe...@sh...
>>>>>>>> at imap.shentel.net. Nov 05 11:42:33 fetchmail: reading message
>>>>>>>> ghe...@sh...@imap.shentel.mail2world.com:1 of 54 (2182
>>>>>>>> header octets) (log message incomplete)
>>>>>>>> Nov 05 11:42:33 fetchmail: client/server synchronization error
>>>>>>>> while fetching from ghe...@sh...@imap.shentel.net Nov
>>>>>>>> 05 11:42:33 fetchmail: Query status=7 (ERROR)
>>>>>>>>
>>>>>>>> I finally logged into the webmail, saw that funky msg and
>>>>>>>> deleted it, which unplugged the drain  and it fetched the other
>>>>>>>> 53 msgs ok.
>>>>>>>>
>>>>>>>> Unforch the log is all I could salvage. Is this helpfull?
>>>>>>> Hi Gene,
>>>>>>>
>>>>>>> thanks for the report. Unfortunately, this log does not suffice
>>>>>>> to check where fetchmail failed - I would need to see a verbose
>>>>>>> log with at least one -v (or possibly -vv if you can spare the
>>>>>>> disk logging space).
>>>>>> That -vv I assume goes in my user .fetchmailrc?
>>>>> On the command line, you can't use it from .fetchmailrc.
>>> And it didn't take long to get a replay.
>>>
>>> This is the message in its entirety from a kmail v entry:
>>> =====================
>>> ...
>>> =====================
>>> And this is the corresponding log:
>>> But its not, with the -vv, its not reporting a Query status=7, just
>>> a 1 now,=no mail but mail has stopped again. I'll log into webmail
>>> and see. Humm, no mail. None of those ipv4 addresses above are me. I
>>> should be that from the web link in the sig.
>> Hi Gene,
>>
>> Well, the more interesting part is really the IMAP dialogue from the
>> -v or -vv verbose log in such cases to figure where the conversation
>> goes out of synch and if it's the server messing up or fetchmail.
>> Reason is that there may be subtle differences on the server-side how
>> the server presents messages with missing parts.
>>
>> Either the message got marked read and not downloaded a 2nd time by
>> fetchmail (in that case, you can download again with fetchmail -q
>> followed by: fetchmail -Nvvd0 -a 2>&1 | tee fetchmail.log), or deleted
>> after fetch (in that case we need to wait for the next occasion,
>> possibly you want to run fetchmail output to a log).
> I see, but looking at the log again just now, it has lost the -vv, then
> it reminded me that another script had been run since I restarted
> fetchmail and it, sa-train-bayes was restarting fetchmail w/o the -vv.
> so thats fixed now. And fetchmail is blabbering like an idiot, 20+ lines
> of output per new mail scan 120 seconds after the last one.  So now we
> wait.  Since the last such instance was 4 or so months back, it may be a
> while, but it will be easier to find since its now logging times again.
>
> Thanks for the update Mathias.  Take care & stay well now.

Gene,

If the logging seems excessive, we may also get away with just -v
instead of -vv for this case. That would also contain the IMAP or POP3
dialogues.

You may also want to rotate and compress logs more often.

Cheers,
Matthias