Closed Bug 278283 Opened 20 years ago Closed 19 years ago

Send/Recieve mail stops working after running Tbird overnight.

Categories

(Thunderbird :: General, defect)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 173924

People

(Reporter: burlo.stumproot, Assigned: mscott)

Details

Twice now I have had Thunderbird v1.0 running overnight and it seems like sending and recieving mail stops working somtimes during the night. When I try to send mail it just hangs when connecting to the SMTP server until I press cancel (I waited several minutes). Pressing get new messages seems to do nothing. A restart of Thunderbird removes the problem and I recieve several hours old emails and sending a messages takes under a seacond again. Extra info: I have 3 pop email accounts but they all use the same SMTP server. I use the Mozilla Calendar plugin v 2004121718-cal WinXP Pro SP2
I experience the same problem very reliably. After about an hour of running, I no longer receive mail and the send function stalls at "Sending message...". It does not time out, it just stays until I cancel it. I have several pop accounts and a single IMAP account all set to automatically check mail for me. Is it possible that there is a threading issue or a conflict between checking and sending at the same time? This seems suspect.
I get this almost daily now, and you don't have to run it overnight, it happens during the day after several hours. This has happened for many versions of Thunderbird now. Workaround when Sending: Cancel Send Save Messages Shut down / Restart Thunderbird Edit Messages in Drafts Send Again
Status: UNCONFIRMED → NEW
Ever confirmed: true
Yeah, this happens for me all the time using 1.0.6. I check 10 POP3 accounts, 1 IMAP account an RSS account and news, and they all stop working at once, about 8 times a day. I've got used to quitting the app every ten minutes so I get mail, and am pretty much going back to Outlook when I have time to move them all back. Looks like this bug has been around since 0.4... I find I can trigger this every time by selecting "Get Mail" when in the news or RSS account.
Josh, if you can reproduce this, I'd be happy to work with you to try to figure out what's going on. In the news case, does clicking get msgs ever work, i.e., retrieve new messages? One thing that will block all networking is a dns lookup that hangs in the OS - this should be rare, but it can happen. In trunk builds, we've added timeouts to everything, which helps in some situations.
Hi, It appears to be something like that: This causes a problem every time: 1. In Local Folders select "Get Mail" 2. Select a newsgroup in my newsgroup account 3. Thunderbird says it is Looking up "<mailserver>..." Nothing happens. No new news, no new mail/empty account messages 4. Select Local Folders again, the message clears and I can't get Mail or News anymore, either it sticks on "Looking up <mailserver>..." or nothing at all happens. All the other accounts (RSS/IMAP) also don't work. The same results (3. & 4.) occur regularly if I leave Thunderbird running in the background for a few hours. I'm away on holiday for a few days in about an hour, but will be back on Wednesday - feel free to e-mail any suggestions before then (or post them here) and I'll try them if poss.
Do you click on the news group while the get mail is still running in local folders? Does it work if you just get mail run in local folders, and don't click on newsgroups, or does clicking get new mail in local folders always stall? Do you have a pop3 server that defers to the local folders but isn't actually reachable? DNS lookups should eventually timeout. And do you have a virus checker or firewall that might be stalling things?
Do you click on the news group while the get mail is still running in local folders? Yep. Does it work if you just get mail run in local folders, and don't click on newsgroups, or does clicking get new mail in local folders always stall? The majority of the time, this does work, but if I leave thunderbird running for a few hours it does exactly the same thing as if I switch to newsgroups - it's just another way of causing the same problem. Do you have a pop3 server that defers to the local folders but isn't actually reachable? DNS lookups should eventually timeout. The servers are all reachable, although sometimes the log-ins fail - I'm using the following: inmail.joshwatson.f2s.net pop.gawab.com (x2) pop.mail.ru pop.virgin.net 127.0.0.1 (MrPostman Hotmail/Yahoo->POP proxy, 1 yahoo 3 hotmail accounts) - this doesn't work for hotmail at the mo, but rejects the login and disconnects. pop3 (our intranet mail server) And do you have a virus checker or firewall that might be stalling things? I have AVG anti-virus, but have disabled the e-mail module as we sometimes use the pop3/smtp ports for remote telnet access and it messes this up. I'm running XP SP2 with the firewall turned off on all networks, and no other firewalls running.
Hmm, I've been trying repeat this and it doesn't happen every time (I said it did in Comment #3) - it just happens a lot of the time when i carry out those steps. It completed OK a couple of times, even switching to the news server mid-mail receive. Josh
I'm still getting this consistently every morning i have to shut down Tbird and relaunch it.
I tried the local folders/newsgroup thing a few times and it didn't cause a problem...perhaps it depends on what each process is doing. When you click on the newsgroup, is it more likely to happen the first time, or after the connection has timed out, so that it would be doing a dns lookup? News caches nntp connections, but they timeout after 3 or 10 minutes (can't remember which).
I have a customer with two machines that this also occures on. (He leaves them both running overnight.) Any idea if this will be fixed in 1.5?
no, but I believe this is fixed in trunk builds. I believe this is a dup of bug 173924 and I'm marking it as such. *** This bug has been marked as a duplicate of 173924 ***
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.