Hangs at "Getting number of messages..."

[Brian Morrison]

On Wed, 05 Apr 2000 13:21:33 +0100 (BST), Simon Bowring wrote:

>Since something else (sendmail?) receives your email and places
>into a local directory, and you have email messages that apparently 
>cause your problems to occur, there *should* be no difficulty in 
>others reproducing this problem.

The only messages that PMMail will not fetch are where there is no
From: header, in this case the last fetch time updates but the message
file is never retrieved. When the hangs occur, a restart fetches
exactly the same messages from the same directory. BoB told me that the
fetch time is the last thing that the routine does when a fetch is
commanded, it looks to me like the fetch never starts, or that the
location to fetch from is somehow corrupted. PMMail holds the account
ini file contents in memory while it is running, so overwriting this
will 'lose' incoming mail.

FWIW, both sendmail and weasel deliver smtp mail that exhibits this
effect. I don't think it is MTA related, I have concocted an email or
two in a text editor and they also fail in the same way. It's almost
like PMMail can't see the directory, but the failure to update the
fetch counter is key to it. BoB thought he'd fixed it a while back, he
said that something wasn't thread safe on simultaneous fetches, but I
disproved that by altering the timers so that the fetches go out of
sync after an half an hour or so. I have not checked that my other
accounts fail at the same time, but experience tells me that it is busy
active accounts that suffer, the others seem to be OK all the time.
Looks like a possible memory leak to me.

>
>If you are able to do a virgin installion of PMmail (maybe on a 2nd
>machine), populate the appropriate directory with mail messages that
>are expected to cause problems, and see if the problems persist.
>If they do, you should then be in a very strong position to argue 
>your case with Blueprint that the problem is reproducable and
>must be fixed.

This does not work, as I say it is something that happens while
PMMail/2 is running after some amount of time and activity.

>
>If you cannot reproduce your problems this way, then it's unlikely
>that blueprint will be able to as well, making it unlikely that they 
>will be able to provide a fix.

They should be able to provide a build that logs step by step which
routines are run at each fetch, then it is easy to see where the
problem is occurring. I can afford a few megs of disk space for this to
happen.

>
>One encouraging thing is that the problem appears to be 
>"self-contained" within your pmmail installation and email 
>dir, and is not related to interactions with a remote mail 
>server, so a zipped up pmmail and email dir from your machine
>*may* allow blueprint to investigate.

Maybe, but they would need a source of incoming smtp-delivered mail as
well.

I don't use POP3 much, Demon's POP3 implementation is the reason why
there is a 'Quick interrogation' checkbox in PMMail, this needs turning
off for mail from there as the POP message index is rebuilt on the fly
because POP3 is an add on to the smtp spools. As such, the message
number can change (POP3 spec says that the UID is the *only*
characteristic of a message that can't change) between connections and
PMMail used to fail to retrieve correctly. BoB fixed this, but at the
cost of speed. Apparently no one else has a POP3 implementation like
this, I had to temporarily allow access to my POP3 account so that BoB
could debug it. Demon are fully RFC compliant, it's just that BoB made
an assumption about POP3 based on observation of other servers that
didn't hold for the one I use.

-- 
Brian Morrison                                  bdm@fenrir.demon.co.uk
              do you know how far this has gone?
               just how damaged have I become?
                                      'Even Deeper' by Nine Inch Nails