Thunderbird complains there is no connection on resume from suspend, when there is a connection

[Michael Doube]

Binary package hint: thunderbird

When I resume from suspend, network manager quickly re-establishes a WiFi internet connection. With an active connection, I try to check my mail with Thunderbird, but it complains that it can't connect to the IMAP server. This seems to happen after longer suspend periods because if I try to replicate the behaviour by quickly suspending and resuming (suspend of a few seconds), I get no warning.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: thunderbird 3.0.4+nobinonly-0ubuntu4
ProcVersionSignature: Ubuntu 2.6.32-22.33-generic 2.6.32.11+drm33.2
Uname: Linux 2.6.32-22-generic x86_64
Architecture: amd64
Date: Sun May 23 12:26:28 2010
InstallationMedia: Ubuntu 10.04 "Lucid Lynx" - Alpha amd64 (20100412)
ProcEnviron:
 LANG=en_GB.utf8
 SHELL=/bin/bash
SourcePackage: thunderbird

[Micah Gersten (micahg)]

Thank you for reporting this to Ubuntu. Does it then work on the second try? This usually works for me.

[Michael Doube (michael-doube)]

Michah, yes, I have to flick back to another folder, say "Sent Items", then to Inbox for Thunderbird to stop complaining and become aware that there is an active connection, as well as dismiss all the "no connection" warning dialogs (painful if there is more than one account it is checking).

[Micah Gersten (micahg)]

I can confirm this. This should probably be upstreamed.

[Michael Doube (michael-doube)]

User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.2.3) Gecko/20100423 Ubuntu/10.04 (lucid) Firefox/3.6.3
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4

When I resume from suspend, network manager quickly re-establishes a WiFi internet connection. With an active connection, I try to check my mail with Thunderbird, but it complains that it can't connect to the IMAP server. This seems to happen after longer suspend periods because if I try to replicate the behaviour by quickly suspending and resuming (suspend of a few seconds), I get no warning.

This could be a duplicate of the reported fixed bug
https://bugzilla.mozilla.org/show_bug.cgi?id=473483
although that one was reported against Mac OSX.

Reproducible: Always

Steps to Reproduce:
1. Open Thunderbird, check mail
2. Suspend laptop, let it sleep for a while
3. Resume laptop, wait for connection, go to inbox
4. Thunderbird complains there is no connection
5. Mail can be read by going to some other folder, then back to Inbox
Actual Results:
Thunderbird complains there is no connection

Expected Results:
Thunderbird checks mail without complaining

Reported on Launchpad:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/584529?comments=all

[Michael Doube (michael-doube)]

This could be a re-emergence of https://bugzilla.mozilla.org/show_bug.cgi?id=473483, which was meant to be fixed more than a year ago

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

Anything in Tools->Error console ?

If you launch tb from a terminal anything on that terminal's stdout ?

[Michael Doube (michael-doube)]

Nothing in stdout

In Tools->Error Console I see this, several times:
Error: [Exception... "update.locale file doesn't exist in either the XCurProcD or GreD directories" nsresult: "0x80520012 (NS_ERROR_FILE_NOT_FOUND)" location: "JS frame :: file:///usr/lib/thunderbird-3.0.4/components/nsUpdateService.js :: getLocale :: line 549" data: no]
Source File: file:///usr/lib/thunderbird-3.0.4/components/nsUpdateService.js
Line: 549

Will keep an eye on this log.

[Hector (hsanjuan)]

I can confirm this bug. It happens on first click on "receive messages" every time I come back from suspend after "a while" as Michael notes. It happens with POP accounts, not only IMAP. Second click on "receive messages" works fine.

Perhaps this "while" is the "check for messages every X minutes" time?

No relevant information on stdout or error console.

I have Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.9.1.10) Gecko/20100520 and ThunderBird 3.0.5

[Michał Gołębiowski-Owczarek (mgol)]

There is a launchpad bug here:
https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/587512

[Michał Gołębiowski-Owczarek (mgol)]

Sorry, seems a dup.

[Micah Gersten (micahg)]

Marking this Triaged as we have an upstream bug.

[Hector (hsanjuan)]

It seems no one's working on this one even when it is quite annoying, but at least status should be changed to "confirmed"

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

(In reply to comment #6)
> It seems no one's working on this one even when it is quite annoying, but at
> least status should be changed to "confirmed"

Why we don't reproduce - so mightsomething external causing the issue.

[Michał Gołębiowski-Owczarek (mgol)]

Upstream cannot reproduce it, so maybe it's Ubuntu's fault?

[Michał Gołębiowski-Owczarek (mgol)]

So maybe some OS pattern? I use Ubuntu 10.04 amd64 with Thunderbird 3.0.6.

[Hector (hsanjuan)]

I use opensuse 11.3 TB 3.1.2, NetworkManager and nm-applet as frontend

[Michael Doube (michael-doube)]

Ubuntu 10.04 amd64 TB 3.0.6 here too.

[Stefan Oschkera (steff35)]

Ubuntu 10.04, issue persists also in TB version 3.0.10

[Julian Sikorski (belegdol)]

https://bugzilla.redhat.com/show_bug.cgi?id=510005
I believe Fedora 14 also has this problem. On the other hand, firefox in Fedora can detect the connection state and go to offline mode, so this seems possible.

[Hcgpalm (hcgpalm)]

I can confirm that this also happens with Fedora 14/TB 3.1.6 using NetworkManager/nm-applet.

After resuming from suspend I always get the "Failed to connect to server" pop up for every account the first time I hit "Get Mail" for that account, unless I give it enough time to make an automatic background check (which, by the way, seems to take a *very* long time after resuming - a lot longer than the configured 10 minute check interval, which is why I always need to click "Get Mail" in the first place). As others have noted, it does not happen for short suspends.

Maybe someone could at least provide some ideas on how this could be diagnosed further?

[Ludovic-mozillamessaging (ludovic-mozillamessaging)]

A nsSocketTransport:5 log might help .

[Matthias G. (matgnt)]

Seems to be solved in the latest thunderbird update for 10.04 (thunderbird 3.1.7+build3+nobinonly-0ubuntu0.1).

[Matthias G. (matgnt)]

To correct myself, it's not really solved, but the annoying popup message is gone. The message now (sometimes) appears through the desktop notification system in the top right corner.

[Stefan Oschkera (steff35)]

As mentioned above, Thunderbird has been recently updated to 3.1.7 in Lucid (10.04 LTS). I confirm the observations of Matthias (#23): the issue still persists, though it's now less annoying, as the error message is handled/displayed by Ubuntu's notification subsystem, which at least doesn't require to take any further action by the user. Personally, however, I wouldn't consider the issue as resolved.

[Michael Doube (michael-doube)]

10.10 has handled this in the notification area for a while now but I agree with Stefan, the underlying issue is not solved. Thunderbird is still complaining and I still have to click on an Inbox to kick it into action.

[Hcgpalm (hcgpalm)]

Created attachment 499753
nsSocketTransport:5 log

nsSocketTransport:5 log demonstrating the problem. The log was taken from a TB instance with a single IMAP account.
2010-12-25 21:58:42.339538 TB starts
2010-12-26 00:47:59.055689 Last log entry before suspend
2010-12-26 09:02:30.261338 First log entry after wakeup
2010-12-26 09:02:53.550120 First "Get Mail" click (fails) (?)
2010-12-26 09:02:57.739030 Second "Get Mail" click (successful) (?)
2010-12-26 09:03:08.135790 Third "Get Mail" click (successful) (?)

[Hcgpalm (hcgpalm)]

I don't have any experience of interpreting nspr logs, so take this with a grain of salt...

It seems that almost immediately after wakeup, TB tries to re-establish the connection but hostname lookup fails (NS_ERROR_UNKNOWN_HOST). This probably makes sense because the network is not yet up at that time.

After a while, I click "Get Mail". TB tries to open a new connection, but immediately fails again with NS_ERROR_UNKNOWN_HOST. It appears that this result is cached from the previous attempt.

I will add resolver logging too to see if that gives additional any insight.

[Hcgpalm (hcgpalm)]

Created attachment 499762
nsSocketTransport:5,nsHostResolver:5 log

Another log adding nsHostResolver:5. The behaviour was a little bit different this time in that it actually updated the mailbox before I got a chance to hit "Get Mail" a second time. First time, though, I got the error message as usual.
AFAICT it confirms that nsHostResolver is indeed caching the initial lookup failure (timestamp 2010-12-26 15:54:33.688102).
It appears that nsHostResolver treats any lookup failure as NS_ERROR_UNKNOWN_HOST which is perhaps a bit too naive. Ideally, it would distinguish between a communication failure and an actual NXDOMAIN condition, and avoid caching the former, or at least use a much shorter cache timeout.

[Vseerror (vseerror)]

does log show anything interesting ?

[Honzab-moz (honzab-moz)]

My theory is, also as Christer mentioned in comment 16, that we try to connect immediately after wake up, but since cached host name has expired we do complete name resolving again. But the system is not up that soon (few milliseconds after the wake up) to return some result. We should then not cache the unknown-host state.

I'm not a linux developer (I don't see this behavior on a Windows machine, but also may be just related to record expiration times) and also I'm not directly a DNS code maintainer (however, I can do the fix my self).

Adding Michal, since he may know better what type of error state we get from getaddrinfo w/o a net connection up on a linux system.

[Hcgpalm (hcgpalm)]

Actually, as I tried to explain, what's going on is this;

1. After wakeup TB immediately tries to reconnect
2. TB calls nsHostResolver to resolve the server name which immediately gets an error because at this time, the network interface is not yet up
3. nsHostResolver treats this error (in fact, any error) as an unknown host, and puts that that "fact" in its cache
4. TB recognizes that the request is not initiated by the user and therefore suppresses any UI level error message

5. User comes around and clicks "Get Mail"
6. TB again calls nsHostResolver to resolve the server name, which returns "unknown host" from its cache
7. This time the request IS initiated by the user so an error message is shown
8. Not until the cache entry expires can the user successfully reconnect

Having said that, it seems that this problem is gone in TB 10.0!

/C

[Honzab-moz (honzab-moz)]

(In reply to Christer Palm from comment #19)
> Having said that, it seems that this problem is gone in TB 10.0!

Thanks Christer. Based on this I close this as WFM.

[mlaverdiere (mlaverdiere)]

In my case, this was still present with TB 10 under Ubuntu 11.10 and now, under 12.04 beta. So I'm not sure it should be marked as invalid...

[Teo (teo1978)]

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.79 Safari/535.11

Steps to reproduce:

Make sure you're not connected to network (in my case it's wifi, dunnow if this is relevant)
Open Thunderbird
Connect to network.
Check that the network connection works by opening a web page in a browser
Go to Thunderbird and click "get mail"

Actual results:

"looked up gmail.com" (or whatever is the mail server domain) appears on the status bar and stays there for a while. Then it disappears.
Mail is not checked, and no error message is shown.
This happens systematically, 100% of the times.

Then I click "get mail" again, and it ALWAYS works the second time.

Expected results:

thunderbird should have connected to the mail server and checked for new messages the first time.

This issue has always existed ever since I've used Thunderbird, back to version 3 or something. On older versions it was only _slightly_ better, in that you would get a baloon notification (or is it called a toast?) saying "unable to connect" and a (wrong) message on the status bar saying "no messages to download" on the first try.

[M-wada (m-wada)]

(In reply to matteo sisti sette from comment #0)
> Actual results:
> "looked up gmail.com" (or whatever is the mail server domain) appears on
> the status bar and stays there for a while. Then it disappears.
> Mail is not checked, and no error message is shown.
> This happens systematically, 100% of the times.
> Then I click "get mail" again, and it ALWAYS works the second time.

This phenomenon can occur if IPv6 relevant problem exists in your environment.
- first DNS lookup(IPv6 address resolution) takes very long
  => timeout, Tb is unable to login.
- upon second DNS lookup by Tb, IPv6 address resolution is alrweady done by
  first request, then second DNS look up ends within a shor period.
This started to occur from Tb 3, because defaullt of network.dns.disableIPv6 was changef rom true to false by Tb 3.

What happens if network.dns.disableIPv6=true is set?
(restart Tb after setting change to avoid needless problems)

[M-wada (m-wada)]

Because Wifi, wireless connection is established upon first network request from PC. It may take long and first DNS Lookup by Tb may timeout.

How long does "first ping(or tracert) imap.gmail.com after re-boot" take in your environment?
(1) Re-boot PC, (2) First "ping imap.gmail.com", (3) Second "ping imap.gmail.com", (4) Start Tb with network.dns.disableIPv6=false(default) or true, (5) Gmail IMAP folder access, Get Msgs etc.

[Steve Chapel (schapel)]

I can confirm this is an issue in Thunderbird 12 on Ubuntu 12.04.

[Michael Doube (michael-doube)]

Another version combination where this bug is still present:

Ubuntu 11.04 with Thunderbird 13.0.1 (from the PPA)

[mlaverdiere (mlaverdiere)]

I'm on Ubuntu 12.10 beta 2 with TB 15.0.1 and so far, I don't experience this bug anymore.

[Vseerror (vseerror)]

matteo, can you reply to comment 2 and comment 1?

[Vseerror (vseerror)]

Vincent, Steve, can you reproduce?

[Teo (teo1978)]

Reply to comment 1: Exact same behavior after setting network.dns.disableIPv6=true (and restarting Tb) (tested twice)

Regarding comment 2: too much work to test, however the premise "connection is established upon first network request" doesn't make any sense to me. Also note the fourth step in "steps to reproduce".

[Steve Chapel (schapel)]

Yes, I can reproduce with Thunderbird 17.0.2 on Ubuntu 12.04.

[Vseerror (vseerror)]

This needs more analysis.

It would not surprise me if this is already described in a hard to find (duplicate) bug.

[Vseerror (vseerror)]

 matteo, is not the precise wording of what you see "Failed to connect to server"?
(*not* "unable to connect")

[Teo (teo1978)]

Wayne, neither of the two!!!!
As I mentioned in my report, what I see is "Looked up gmail.com..." (which is complete nonsense) and then nothing. It doesn't show any error message at all.

IN SOME PREVIOUS VERSION it did show an error message, but I can't check now the exact wording; it may well have been "Failed to connect to server", as you say.

[M-wada (m-wada)]

(In reply to matteo sisti sette from comment #10)
> As I mentioned in my report, what I see is "Looked up gmail.com..."
> (which is complete nonsense)

This message/situation is same as "when FQDN is not found in DNS", and is easily seen by POP3 definition with dummy/non-existent server such as x.x.x.
The messag is "DNS is looke up".
What is base of your "nosense" on message related to DNS look up?

> and then nothing. It doesn't show any error message at all.
> IN SOME PREVIOUS VERSION it did show an error message,
> but I can't check now the exact wording;
> it may well have been "Failed to connect to server", as you say.

With POP3 definition with dummy/non-existent server such as x.x.x, old Tb showed connection error message when server is not found in DNS.
Recent Tb stopped annoying connection error error message.
  While looking up DNS, "Looking up".
  After end of DNS look up, "Looked up".
  If server is not found, stop further action,
  because trying to connect to non-exstent server is nonsense.

Because phenomenon with Wifi and phenomenon is when Wifi router doesn't have server connection yet, it may be following.
- In PC, DNS server is defined as 192.168.0.1.
- Wifi router's local IP address is 192.168.0.1
  i.e. Wifi roter behaves as proxy server to DNS, or a DNS server.
- Wifi router gets actual DNS address of his provider upon connection
  establishment with his server.
- Wifi router returns "not found", if actual IP address of DNS of his
  provider is not known yet.

If you　can reproduce your problem consistently,
(A) Before you try to connect to server from Tb,
connect to 192.168.0.1 from Browser and check Wifi router's WAN side status. Is DNS address set always? If DNS IP address is shown, do "tracert or ping the-ip-address-of-DNS" at Terminal. Is response returned within reasonable period?
Write ddown the actual DNS's IP address.
(B) Actual DNS address is usualy not changed so frequently.
Before you try to connect to server from Tb, do "tracert written-down-ip-address-of-DNS" at Terminal. Is response returned within reasonable period?
(C) How about "tracert or ping ???.gmail.com"?
    IIRC, I already requested this to you in comment #2...

[Teo (teo1978)]

This has nothing to do with the wifi router.
I see the exact same issue when I use a USB mobile broadband modem instead.
(whops, I thought I had already mentioned that, I hadn't).

Also note (again) my steps to reproduce the issue:

 Steps to reproduce:

 Make sure you're not connected to network
 Open Thunderbird
 Connect to network.
 CHECK THAT THE NETWORK CONNECTION WORKS BY OPENING A WEB PAGE IN A BROWSER
 Go to Thunderbird and click "get mail"

So, between connecting to the network and having TB check mail, I check that everything else works by surfing the web with a browser. No matter how much time I wait, the FIRST time TB tries to fetch mail it systematically fails, even if it is several minutes after connecting to network; the SECOND time it succeeds.

Frankly, I wouldn't look for the cause of this outside TB.

By the way, my DNS is NOT defined as 192.168.1.1, it is 8.8.4.4 (Google's DNS).

Regarding the other issue, the NONSENSE is that:
1. when connection to the server fails for whatever reason, no matter whether it is because the host is unreachable or because the name can't be resolved, it must show a message telling you what the failure is (such as "couldn't resolve domain name", or whatever), not a message that tells you what was the last thing it did and which doesn't even tell you whether it was a success or failure! ("looked up xxxx", as in "I looked up the domain. Don't ask me whether I found it or not"). When you tell a program to do something it must end in either or two ways: (a) "I'm finished doing what you asked me: the result is xxxx", or (b) "I couldn't complete the task because something went wrong: the error was xxxxx".
2. Even if you are not connected to the internet at all, it still says "looked up gmail.com"!!!! That's complete nonsense.

[M-wada (m-wada)]

(In reply to matteo sisti sette from comment #12)
> I see the exact same issue when I use a USB mobile broadband modem instead.
> By the way, my DNS is NOT defined as 192.168.1.1, it is 8.8.4.4 (Google's DNS).

If problem happens when no route to internet(phone cable is pulled of from modem), it's perhaps one of next;
- timeout in DNS server access
- Tb's problem when PC's IP address is changed by DHCP retention,
  DNS cache is not cleared, ...
If problem happens when other software like broweser can access to intenet normally, other component of Tb like SMTP can send mail, other mail client can access ...gmail.com with no problem even though Tb fails with "looked up gmail.com", ..., etc.,
it's perhaps one of next;
- timeout in DNS server access i Tb
- Tb's problem when PC's IP address is changed by DHCP retention,
  DNS cache is not cleared, ... (known issues)

If you can reproduce your problem consistently, do following, please.
(i) Before try to access server from Tb, go Work Offline, then go Work Online. This disconnects from server, and restart network connection from scratch. IIRC, DNS cache related issue, IP address change relate issue, is bypassed by this.
(ii) Get DNS server access log with timestamp.
     See bug 402793 comment #28.
> Win example :
> SET NSPR_LOG_MODULES=timestamp,nsHostResolver:5,imap:5,pop3:5
Timeout in DNS server access?

>
>
> Regarding the other issue, the NONSENSE is that:
> 1. when connection to the server fails for whatever reason, no matter
> whether it is because the host is unreachable or because the name can't be
> resolved, it must show a message telling you what the failure is (such as
> "couldn't resolve domain name", or whatever), not a message that tells you
> what was the last thing it did and which doesn't even tell you whether it
> was a success or failure! ("looked up xxxx", as in "I looked up the domain.
> Don't ask me whether I found it or not"). When you tell a program to do
> something it must end in either or two ways: (a) "I'm finished doing what
> you asked me: the result is xxxx", or (b) "I couldn't complete the task
> because something went wrong: the error was xxxxx".
> 2. Even if you are not connected to the internet at all, it still says
> "looked up gmail.com"!!!! That's complete nonsense.

[M-wada (m-wada)]

(In reply to matteo sisti sette from comment #12)
> 2. Even if you are not connected to the internet at all,
> it still says "looked up gmail.com"!!!! That's complete nonsense.
(i) Open separate bug for error message improvement.
    Keep "one proble per a bug" at B.M.O, please.
(ii) Until message will be improved, read "looked up ..." as "looked up ..., but it failed", with complement string like ",but it failed", ",but it's not found", ..., as you like, in your brain, please.

[Vseerror (vseerror)]

(In reply to WADA from comment #14)
> (In reply to matteo sisti sette from comment #12)
> > 2. Even if you are not connected to the internet at all,
> > it still says "looked up gmail.com"!!!! That's complete nonsense.
> (i) Open separate bug for error message improvement.
> Keep "one proble per a bug" at B.M.O, please.
> (ii) Until message will be improved, read "looked up ..." as "looked up ...,
> but it failed", with complement string like ",but it failed", ",but it's not
> found", ..., as you like, in your brain, please.

I also saw this too. I'm not sure if a bug exists for it - I started to look a few days ago but did not finish

wada, thanks for all the ideas. I hope to check some of them. However, my sense is the problem is thunderbrd, because I do not have trouble with firefox.

matteo, please be sure to use exact wording of what you see in messages and dialogs, not approximation. exact wording allows us to better search bugzilla and source code.

[teo1978 (teo8976)]

Sorry I missed this comment:

> matteo, please be sure to use exact wording of what you see in messages and dialogs,
> not approximation. exact wording allows us to better search bugzilla and source code.

I always try my best to do that. However:
- in this case I did use the exact wording of the relevant message being shown in the current version. Where I used an approximate wording it was a message that used to be shown in an age-old version that I didn't have any more, so the best I could do was to mention the approximate message as I remembered it (I certainly won't reinstall an older version just for the sake of figuring out the exact wording of a message)
- in some cases messages are displayed and then vanish. When I'm reporting a bug, I don't always have the time to repeat the steps _again_ in order to see the exact message

and most importantly:
- if you expect users reporting bugs to use the exact wordings, please make sure that all displayed errors, warnings and messages are copy-pastable.

[madpentiste (antoine-messiah)]

I can report a problem with Ubuntu 14.04 (x64, Mate desktop) which is similar as (but not identical to) what was described initially (bug description, or, say, posting #0, and first 20 postings relative to Ubuntu 10.04. Thunderbird version is 31.6.0, and the package is thunderbird 1:31.6.0+build1-0ubuntu0.14.04.1.

When waking up from a long sleep/standby generated by closing the laptop lid, all looks fine, including reading messages, until I try to send a message (a new one, a response to or a forward from an old one) or even if I try to save a draft (this being true even if the draft is set to be saved in the local folder).

I get an error message telling that there was an error, and I should check my account parameters. This happens with all my accounts (which are all IMAPs). The only resort is to close Thunderbird and restart it, in which case the problem disappears. But the work is lost, except if the message to be sent or saved has been exported to an html file, which allows to salvage the lost message by starting all over but not from scratch since the html file is there, to copy from and paste into the message.

I tried the "working offline" followed by "work online" solution described elsewhere, to no avail.

 It looks like a persistent problem, regardless of distro version.

I do not think this should be classified as "medium", as far as this bug is an excellent incentive to switch to other email clients.

[gds (gds-chartertn)]

Wayne, I don't see this problem doing these steps:

1. Make sure ff and tb both working OK, network wise
2. Switch off wifi and verify ff does not access anything.
3. Shutdown tb (all windows)
4. Start tb with wifi off
5. Switch wifi on
6. Verify ff working again, can access a page
7. In tb click "Get Mail". Tb check mails, no waiting, no messages, see immediate connections occur in wireshark.

Tried this on 2 systems with same result using 60.*.

[Vseerror (vseerror)]

Thanks for the test

[Paul White (paulw2u)]

The upstream bugs 569324 and 737241 were both closed "RESOLVED WORKSFORME"
on 2012-12-16 and 2019-02-16 respectively.

I can't reproduce the bug here using either Ubuntu 18.04 or 19.10 and
Thunderbird 60. Can this now be closed or does anyone still have a problem
with Thunderbird not connecting after resuming from suspend?

[Paul White (paulw2u)]

Bug report won't expire due to bug watches
No reply to comment #57 after 40 days so closing as fixed