weather applet loses connectivity permanently

Same problem with bzr from March 9 2010. Rev 1218. If I hibernate my laptop for more than 30 minutes when it resume the weather applet fails to get its updates. Not sure if it is a "urllib2" problem or weather.py. Also if I have the network disabled in network manager (as a test) when I start AWN or load the applet, same thing, except of course the icon stays as the weather channel logo. I slightly patched weather.py to force it to traceback when any network error happens and this is the traceback.

NetworkException in Weather: error in get_forecast: <urlopen error [Errno -3] Temporary failure in name resolution>

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/awn/extras/threadqueue.py", line 64, in run
    r = func(*args, **kwargs)
  File "/usr/share/avant-window-navigator/applets/weather/weather.py", line 159, in bound_func
    result = func(obj, *args, **kwargs)
  File "/usr/share/avant-window-navigator/applets/weather/weather.py", line 188, in bound_func
    raise NetworkException("error in %s: %s" % (func.__name__, e))
NetworkException: error in get_forecast: <urlopen error [Errno -3] Temporary failure in name resolution>

The cause is due to the fact that the applet tries to get the update before NetworkManager has completely restored the network connectivity on thaw/resume.

OT of the bug, I have to say what an excellent job on AWN you guys are doing. the 0.4.0 / trunk is a major improvement over something that was already really good.

I hacked a proof of concept patch to have it check NetworkManager to see if there is at least one active network interface before trying to call urlopen, and it seems to work. I found an example by Dan Williams on getting NM to return the active interfaces, and I butchered it into a function, which returns a delimited list of active interfaces, the keyword "DOWN" if there are none, or "NONM" if the function couldn't talk to NetworkManager. That way if NM is not used, the old behaviour is maintained. So it does appear to be a bug in the urllib2, since not calling urlopen unless NM says there is a working interface seems to keep the symptoms from happening at least for me.

Still can't really reproduce it. I'm using a wifi network right now, of which the connection gets lost sometimes. Just clicking "Refresh" in the context-menu makes Weather try again.

Then it's even more likely to be a python urllib2 bug. I'm noticing it on Fedora 11 with Python 2.6. Trent, what version of python are using 2.6, 2.6.2 or 2.6.4?

I'm using python 2.6.4.

Andrew, to understand you correctly: if you click on "Refresh", does Weather seem to invoke the various functions (get_conditions, get_weather_map, and get_forecast)? You could check by printing some text at the beginning of those functions.

Regarding your #1 comment: you said the exception was thrown before NM could restore the connection. My question is: what happens after NM has restored the connection?

Trent - thanks, that way we know that you and I both see the same thing across different versions of python

Onox - Yes If i click on refresh it does invoke the various functions. The prints that are in the error_cb get invoked with the Warning in Weather: error in get_{forecast,conditions,weather_map}: - urlopen error [Errno -3] Temporary failure in name resolution and then the Reattempt ({3,2,1} retries remaining) in 10 seconds. After those count down the 1 retries it prints, one Error in Weather for each of the get_{forecast,conditions,weather_map} FWIW, I didn't add any prints because the prints in the error_cb seemed answer the question.

If I let it sit there when the next 30 minute timer expires it will repeat the same warning, retries, error for the three gets. If I click refresh manually, it does the same thing.

Even after NM has restored the connection, it continues with the same behaviour as though the network had NOT been restored. It really seems that if there is any call the to urlopen while the network is down doesn't get cleared in urllib2's state, even after the network comes back up.

Even after NM has restored the connection, it (the weather applet) continues with the same ...

So the problem is is that urllib2 keeps raising "urlopen error [Errno -3] Temporary failure in name resolution" exceptions even after NM has restored the connection? Sounds like a bug in urllib2 then. I tried to reproduce it here again with NM (0.8) and after the connection has been restored, the urllib2 exception doesn't get raised anymore and the applet is able to retrieve weather data.
I have python 2.6.4 on gentoo.

Same problem here, guys!
X starts too fast, so that WICD daemon hasn't already connected.
The results is the weather applet fetching condition permanently, without retrieving them ever.
Such a pain in the "back"!
Any solution found?

PS: great job with AWN 4x guys, it rocks!

@katun89: you don't have a org.freedesktop.NetworkManager on your system bus, do you? I'm planning to use the provided patch (with some modifications) but that is only for NM. It could be that WICD has a totally different interface so I cannot make a patch for it unless someone else provides a patch.

I wrote a modular library for network detection in Python a few months ago. I've uploaded it here:

lp:~awn-extras/awn-extras/network-detection

I only wrote an implementation for NetworkManager (because that's all that I have installed here), but it shouldn't be too difficult for someone to write a WICD implementation. Also, it should be useful for any network-using Python applet, not just weather.

I like the weather applet but it is not critical so I really don't care if it can't fetch the weather. Minimally, I would like option to suppress the notifications. Thinking about commenting out parts of weather.py so they don't popup, but not sure where the best spot to edit in the code. Plus if I do this, every time the package gets updated, then my hack will be overwritten...

I get this as well, with notifications appearing quite frequently. It seems to be able to fetch weather forecast data though, so not sure what exactly is failing. I guess it's the "Show map" feature? The notifications are rather annoying and I agree with TimMadden that they are unnecessarily verbose.

These are the errors I get in .xsession-errors:

_map: Couldn't parse weather map
Reattempt (3 retries remaining) in 10 seconds
Warning in Weather: error in get_weather_map: Couldn't parse weather map
Reattempt (2 retries remaining) in 10 seconds
Warning in Weather: error in get_weather_map: Couldn't parse weather map
Reattempt (1 retries remaining) in 10 seconds
Error in Weather: error in get_weather_map: Couldn't parse weather map
Warning in Weather: error in get_weather_map: Couldn't parse weather map

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in awn-applet-weather.

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://help.ubuntu.com/community/ReportingBugs.

I've the same bug on Ubuntu Natty ! It's boring to see an error message each 5 minutes or manual actualisation which says that the weather applet lost connection !

I use AWN - 0.4.1~bzr822-0ubuntu3

Status changed to 'Confirmed' because the bug affects multiple users.