urllib2 timeout issue
Jérôme
jerome at jolimont.fr
Thu Oct 17 09:34:05 EDT 2013
Hi.
Thank you all for your answers.
--------------------------------------------------
Context:
The problem I want to address is the code being stuck too long when the
network is down.
I'm working on a software gateway running on a Raspberry Pi, that forwards
data received through a radio link to the network.
https://github.com/Jerome-github/oem_gateway
This can be sending HTTP requests every 3 seconds, so a 10 secondes timeout
is an issue.
--------------------------------------------------
I was not at home when I wrote my last message. Now back home, I could try on
my own Debian Jessie machine (Python 2.7.5+) and I get the same results as
with the RaspberryPi (long timeout). So there seems to be something going on
with the router/modem.
Wed, 16 Oct 2013 12:04:22 +0200
Vincent Vande Vyvre a écrit:
> The url "dumdgdfgdgmyurl.com/" is just an example ?
Yes.
I wrote dummyurl.com as an example but unfortunately, this actually existed,
so I added gibberish to get a non-existing URL.
Wed, 16 Oct 2013 13:22:34 +0200
Peter Otten a écrit:
> The problem might be ipv6-related.
I do have a inet6 line in ifconfig on my desktop, but nothing on my Pi:
wlan0 Link encap:Ethernet HWaddr 80:1f:02:af:36:e4
inet addr:192.168.1.7 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2644 errors:0 dropped:42297 overruns:0 frame:0
TX packets:982 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:362298 (353.8 KiB) TX bytes:127069 (124.0 KiB)
(I need to connect via Wi-Fi because my ethernet socket is dead thunder
struck...)
And I did this test:
(http://tldp.org/HOWTO/Linux+IPv6-HOWTO/systemcheck-kernel.html):
test -f /proc/net/if_inet6 && echo "Running kernel is IPv6 ready"
IPv6 works on my desktop only, not on the Pi. So it shouldn't be the
culprit, right ?
Wed, 16 Oct 2013 09:06:29 -0700
Tobiah a écrit:
> What happens when you use ping to resolve that address. Do you get
> the same results? If so, I'd say you have a DNS problem. Maybe
> you have two DNS servers listed in /etc/resolv.conf or similar, and
> the first one is unavailable, so it takes 10 seconds to fail over
> to the second working server.
Good point. Same symptoms with ping. Long timeout on machine behind my router,
be it the Pi or the Debian PC.
/etc/resolv.conf:
domain home
search home
nameserver 192.168.1.254
I found this on my server's config:
options timeout:1
I added it to /etc/resolv.conf on my Pi and PC and I get a much shorter
timeout, yet still longer than the value I enter, longer than I expect, and
longer that what I have on other machines (instantaneous).
But at least I see something happening.
--------------------------------------------------
Should I conclude that the issue is in the DNS resolution ?
What can I do then ?
The /etc/resolv.conf trick looks more like a workaround. Besides, this file
is auto-modified. I know I can try to prevent modifications, either by
modifying privileges, or by adding "nohook resolv.conf" to /etc/dhcpcd.conf,
but that does not sound satisfying.
Anyway, it is still not instantaneous.
I don't see anything I can change in my router/modem config (it is closed and
belongs to my ISP, so I can only change what i'm allowed to).
Any other recommandation ?
I'm afraid I'm being out of topic, here.
Back to python, is it normal that urllib2's timeout does not apply to those
DNS delays ?
Is there absolutely nothing I can do from the software side to limit this
delay and give up if no answer is received before a second has passed ?
--
Jérôme
More information about the Python-list
mailing list