After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 551788 - Hangs when network changes
Hangs when network changes
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Mailer
2.24.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
: 487898 555359 557078 646801 650685 659873 670981 671105 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-09-11 09:45 UTC by Johannes Schmid
Modified: 2012-09-12 12:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Backtrace of hung Evolution after suspend & resume (11.55 KB, text/plain)
2009-01-20 14:18 UTC, Jeroen Wouters
  Details
eds patch (1.46 KB, patch)
2012-07-17 12:32 UTC, Milan Crha
committed Details | Review

Description Johannes Schmid 2008-09-11 09:45:02 UTC
When going to a different place while the laptop is suspended and then connecting to a different wireless network on resume (while evo is running), evolution tries to look for new mail but does not succeed but instead simply wait forever on a response.

In addition choosing File->Quit does nothing until it finally quits evolution about 10 minutes later.

Happened twice to me now.
Comment 1 Matthew Barnes 2008-09-11 10:47:51 UTC
Do you have networking issues with any other apps over the course of a suspend/resume?  Web browser, IRC, or anything like that?

Evolution isn't aware of suspend/resume.  Might be that it's still trying to use an open socket from prior to the suspend.  How do other apps handle this?
Comment 2 Johannes Schmid 2008-09-11 11:10:55 UTC
Firefox & Pidgin seems to handle this fine. But you may be right with the open socket but I guess it should be enough to handle the NetworkManager dbus signals correctly without the need to take care of suspend itself.
Comment 3 André Klapper 2008-09-11 12:20:05 UTC
> In addition choosing File->Quit does nothing until it finally quits 
> evolution about 10 minutes later.

Disconnect from the network in nm-applet and reconnect fixes this for me, but it's annoying.
Comment 4 Jeroen Wouters 2009-01-20 14:18:17 UTC
Created attachment 126836 [details]
Backtrace of hung Evolution after suspend & resume
Comment 5 Jeroen Wouters 2009-01-20 14:19:10 UTC
Comment on attachment 126836 [details]
Backtrace of hung Evolution after suspend & resume

I encounter this bug nearly every time I suspend & resume (even when on the same network).
Comment 6 Johannes Schmid 2010-06-30 08:54:46 UTC
This didn't happen anymore since at least GNOME 2.28. Maybe it got fixed with new IMAP code or with Matthew's kill-bonobo stuff.

Feel free to close it if nobody objects.
Comment 7 Milan Crha 2012-05-18 14:57:04 UTC
*** Bug 670981 has been marked as a duplicate of this bug. ***
Comment 8 Milan Crha 2012-05-18 14:59:28 UTC
*** Bug 646801 has been marked as a duplicate of this bug. ***
Comment 9 Milan Crha 2012-05-18 15:00:52 UTC
*** Bug 650685 has been marked as a duplicate of this bug. ***
Comment 10 Milan Crha 2012-05-18 15:01:58 UTC
*** Bug 659873 has been marked as a duplicate of this bug. ***
Comment 11 Milan Crha 2012-05-18 15:02:39 UTC
*** Bug 671105 has been marked as a duplicate of this bug. ***
Comment 12 Adam Williamson 2012-05-18 16:55:53 UTC
Milan, are you _sure_ all of those are dupes? I repeat again that the case me and several others were experiencing on one of the dupes certainly doesn't date back to 2008, and does not depend on changing wireless networks. Or wireless networks at all. This system is on an Ethernet connection. Every single time I suspend and resume, Evolution permanently loses network connectivity until it is restarted. This did not happen with Fedora 16, which restricts the timeframe to late 2011 onwards.
Comment 13 dmotd 2012-05-18 23:13:04 UTC
I am being referred here from Bug 670981. The behaviour described here does not exactly match the experience of the referring report, and while this bug dates from 2008, Bug 670981 relates only to versions > 3.2. I maintain that this is a new bug and the last known working version was 3.2.3 (with gnome 3.2).
Comment 14 Cosimo Cecchi 2012-05-18 23:45:46 UTC
FWIW this appears to work correctly with Evolution 3.5.1.
Comment 15 André Klapper 2012-06-18 10:34:24 UTC
*** Bug 487898 has been marked as a duplicate of this bug. ***
Comment 16 André Klapper 2012-06-18 10:35:24 UTC
*** Bug 555359 has been marked as a duplicate of this bug. ***
Comment 17 Jean-François Fortin Tam 2012-06-23 14:57:16 UTC
FWIW, with the 3.4.3 release that came in through my distro (F17) updates today, it now seems to work (I have not *thoroughly* tested though... others are welcome to confirm), compared to 3.4.2.
Comment 18 Yves-Alexis Perez 2012-06-25 11:35:01 UTC
Well, it doesn't seem to get really better. I've tried this morning:

* suspended the laptop without making evolution offline
* resumed in another network
* evolution is spinning there, not managing to refresh anything
Comment 19 Adam Williamson 2012-06-25 16:10:54 UTC
The suspend/resume case does seem to be working in 3.4.3, I guess that's what J-F has. I've suspended/resumed twice since getting 3.4.3 and it's worked both times.
Comment 20 Yves-Alexis Perez 2012-06-25 16:49:26 UTC
I'm not sure about simple suspend/resume case, but this is about network changes, and it doesn't work fine here.
Comment 21 Milan Crha 2012-07-17 11:11:33 UTC
I think this is related to nspr/nss, which is used for SSL connections in mailer part. I just tried to reproduce this with IMAP, which is connecting to my server, which is hidden under vpn. Going to suspend and then resume makes vpn connection drop, nonetheless, after several seconds (up to a minute), the connection timeouts and an error is reported to the user in UI. This is with:
   nspr-4.9-2
   nss-3.13.4-3

I guess my vpn scenario covers Yves-Alexis' case too, because when I run vpnc again, then Evolution will connect to the server and work like nothing happened again.
Comment 22 Milan Crha 2012-07-17 11:26:24 UTC
(In reply to comment #21)
> I guess my vpn scenario covers Yves-Alexis' case too, because when I run vpnc
> again, then Evolution will connect to the server and work like nothing happened
> again.

Oops, nope, I was too quick in speaking. I am able to partially reproduce this. After resume, if I click Send/Receive, then it is stuck. I can cancel it by Cancel button or Cancel all (it's necessary to cancel it). Then the next Send/Receive works as expected. I'll check how to set timeout on the connection, to not wait too long. 60 seconds might be fine, I believe.
Comment 23 Milan Crha 2012-07-17 12:32:16 UTC
Created attachment 219014 [details] [review]
eds patch

for evolution-data-server;

With this patch the connect, read and write operations on TCP streams use one minute timeout, thus if connection gets suddenly lost, the request timeouts. Previously used functions PR_Read/PR_Write didn't allow timeout setting, though here is obvious that the connection is done over network, not locally.
Comment 24 Milan Crha 2012-07-17 12:36:44 UTC
Created commit 86160aa in eds master (3.5.5+)
Created commit a511ec3 in eds gnome-3-4 (3.4.4+)
Comment 25 Milan Crha 2012-09-07 13:03:11 UTC
*** Bug 679319 has been marked as a duplicate of this bug. ***
Comment 26 Milan Crha 2012-09-12 12:58:31 UTC
*** Bug 557078 has been marked as a duplicate of this bug. ***