Red Hat Bugzilla – Bug 975193
geolocation works haphazardly
Last modified: 2014-04-17 09:49:18 EDT
Description of problem:
This is a problem found in bug 975159. If I boot F19 TC3 Live and start Anaconda, sometimes I get Czech language pre-selected, but usually I get English language pre-selected. If I quit Anaconda and start it again, I get Czech pre-selected. I'm located in a Czech network.
I guess the geolocation requests are taking some time and Anaconda doesn't wait for the reply, so sometimes it works and sometimes it doesn't? But I have no idea why it always work if I run Anaconda for the second time in the same session.
Version-Release number of selected component (if applicable):
always, but hard
Steps to Reproduce:
1. Connect from a network that is detected as in Czech Republic (that is not Red Hat's Brno office, by the way).
2. Boot Live and run Anaconda
3. If English is pre-selected, quit Anaconda and run it again. Czech should be pre-selected now.
the location detection usually fails to detect user's location
the location detection doesn't seem random and works the same in most cases
Attaching logs. I ran Anaconda (it detected English), quit it. Then run Anaconda again (it detected Czech), and quit it.
Created attachment 762159 [details]
Created attachment 762160 [details]
Created attachment 762161 [details]
Yeah, there is currently sort of race between the GUI showing up and GeoIP lookup finishing. On non-live installs, quite a lot of stuff needs to be started (such as for example X and loading GTK to memory), so the lookup has more time to finish before the GUI shows up.
On the other hand, on live installs, most stuff is already loaded and the Anaconda interface shows up very quickly. So it can easily happen, that that lookup, that usually takes up about 1-2 seconds finishes after the GUI is already shown.
I've just submitted a patch for review, that makes anaconda wait for up to 3 seconds for the GeoIP lookup to finish, before showing the GUI. This should make geolocation on live installs work more consistently, at the cost of making the Anaconda interface startup longer by about a second (and in worst case by 3 seconds).
So a fix has been pushed and should be part of the next version (20.2-1). It wait for up to 3 seconds for Geolocation to finish - so please test and report in case that the timeout is too short.
For the record, could you post how you chose 3 seconds?
(In reply to Steve Tyler from comment #7)
> For the record, could you post how you chose 3 seconds?
It seems that all GeoIP queries I've done so far take between 1 and 2 seconds, so I've used the worst case and added a 50% margin.
But I take the 3 seconds as an initial guess, if anyone finds that it is too short in some scenario, it can be changed.
(In reply to Martin Kolman from comment #8)
> (In reply to Steve Tyler from comment #7)
> > For the record, could you post how you chose 3 seconds?
> It seems that all GeoIP queries I've done so far take between 1 and 2
> seconds, so I've used the worst case and added a 50% margin.
> But I take the 3 seconds as an initial guess, if anyone finds that it is too
> short in some scenario, it can be changed.
Thanks, Martin. If the GeoIP server gets busy, so that the reply takes longer than 3 seconds, is there a way to trigger a refresh?
(Without restarting the installer ...)
I have to say the developer choice is very hard here. On the initial screen you can display some button to re-trigger to geo check and update the language when the GeoIP server is slow to respond, but 1) the language list is already visible 2) the button will be described in an incorrect language anyway. So it's a question whether the new button brings anything useful other then cluttering the screen.
I think Martin followed the best approach here - wait for a reasonable timeout, and if we don't receive a reply, just display the language selector. In that phase, the user can pick the language manually and a button to re-trigger geo lookup would bring hardly any benefits.
(In reply to Steve Tyler from comment #9)
> (In reply to Martin Kolman from comment #8)
> > (In reply to Steve Tyler from comment #7)
> > > For the record, could you post how you chose 3 seconds?
> > It seems that all GeoIP queries I've done so far take between 1 and 2
> > seconds, so I've used the worst case and added a 50% margin.
> > But I take the 3 seconds as an initial guess, if anyone finds that it is too
> > short in some scenario, it can be changed.
> Thanks, Martin. If the GeoIP server gets busy, so that the reply takes
> longer than 3 seconds, is there a way to trigger a refresh?
> (Without restarting the installer ...)
No, way to refresh at the moment & not really planed because of how GeoIP is supposed to work:
* fully automatically
* only preset values and don't skip them
* don't change any settings that the user has already changed or even seen
So once the Welcome spoke is visible, user can just select the correct language by himself, not much point in using GeoIP at that point. Even a "refresh geoip" button would be IMHO kinda pointless as the user knows what language he wants and can just select it outright.
BTW, even if the GeoIP language preset times out, the actual GeoIP lookup is still running in the background and if it finishes before the user clicks "done" on the Welcome spoke, the result will be used to at least preset the timezone.
Thanks, Kamil and Martin, that's very helpful.
I wasn't thinking of a geoip refresh button, but a user action from the existing GUI that would trigger a geoip refresh ...
From a wireshark capture, it appears that the installer connects to:
Is the geoip server configurable?
This would be useful for stress testing and fault injection.
I don't see any such option in the documentation:
Snippet from anaconda-19.30.13-1/docs/boot-options.txt:
=== inst.geoloc ===
Configure geolocation usage in Anaconda. Geolocation is used to pre-set
language and time zone.
`inst.geoloc=0`:: Disables geolocation.
`inst.geoloc=provider_fedora_geoip`:: Use the Fedora GeoIP API (default).
`inst.geoloc=provider_hostip`:: Use the Hostip.info GeoIP API.
Has been implemented/fixed in the Fedora 20 time-frame, so closing. Please open new RFE bugs for any improvement ideas, such as those discussed in comments 7-12.