Hi Grant, > >>>> I've been experimenting recently, in version 0.71, with connman's ability > >>>> to > >>>> launch the NTP daemon in one-shot mode when the service state transitions > >>>> to > >>>> online mode. > >>>> > >>>> However, what I notice in practice is that when the time server is any > >>>> named > >>>> entity (e.g. time.ubuntu.org or pool.ntp.org), the NTP daemon fails to > >>>> resolve the name, ntpd_intres gets forked and launched and then > >>>> indefinitely > >>>> fails to resolve the name. > >>>> > >>>> If I rework the plugin to delay NTP start up and then periodically retry > >>>> several times over time, I see the same results: NTP never successfully > >>>> resolves the name. > >>>> > >>>> If I run tcpdump while connman is starting up and bringing up the > >>>> service, > >>>> I > >>>> see requests going out for wpad.<mydomain> to the name server; however, I > >>>> never see a resolve request going out on the wire for the time server, > >>>> ever. > >>>> > >>>> If I manually run the NTP daemon in one-shot mode, the name resolves > >>>> immediately and time is updated. If I run nslookup on the time server > >>>> while > >>>> all these retries and failures are occurring from the instance dispatched > >>>> in > >>>> connman, the name resolves successfully. > >>> > >>> So what I am thinking is that we might have a small race condition here > >>> where the built-in DNS proxy is not yet ready to answer DNS queries > >>> properly. Can you try to run connmand with --nodnsproxy and see if this > >>> changes at all. > >>> > >>> We could still have the problem that we do not write /etc/resolv.conf > >>> early > >>> enough. > >> > >> I thought the same thing initially, hence the experiment to introduce a > >> delay (I tried up to 30 seconds) in starting the NTP daemon once the sync > >> method is invoked. No matter the length, the delay made no difference. > >> > >> My default /etc/resolv.conf is the same that connman writes out anyway, so > >> the only "hole" that might get hit is truncate before the new file gets > >> written (see below regarding res_int why this shouldn't matter though). > >> > >> Other experiments I tried with no success: > >> > >> [ ... experiments omitted ... ] > >> > >> In all seven cases, running the NTP daemon in one-shot mode indefinitely > >> fails to resolve a name. In all seven cases, running the daemon outside of > >> connman or running nslookup on the name succeeds immediately. > >> > >> Looking at the ntpd_intres code, it repeatedly calls res_init(), so if > >> there > >> were a race or some such, I would expect it'd eventually recover on one of > >> it's subsequent retry attempts. > > > > maybe you are hitting a GLibc bug. The res_init() with a > > static /etc/resolv.conf should just work fine. > > > >> Any suggestions on other experiments to run would be welcomed. > >> > >> At this point, my next step may be to try calling the connman > >> g_resolve_lookup_hostname while building the temporary configuration peer > >> list. > > > > Try to have ConnMan resolve the name before calling the ntpd one-shot > > command line and give the IP address to that one. I am curious if that > > would work. > > As suggested above, if I set up a new gresolv instance and call > g_resolv_lookup_hostname from ntpdate_add_peer, it works consistently (see > output below). Would you like a patch for this?
as a short term solution, I am fine with trying to resolve the IP address before calling ntpd. Just keep in mind that you need to check if the server name might be already an IP address. In case of DHCP it is possible that it hands out IP addresses directly. The only small downside I see is that normally pool.ntp.org is round robin DNS server and hands out more than one address. However since we do one shot only anyway, just picking the first address should be fine. That all said, I am still curious what happens with ntpd and name resolving that this causes so many problems. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
