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: > > 1) Changed connman such that it does not write out /etc/resolv.conf. > > 2) Changed /etc/resolv.conf such that it has the static name server > configuration appropriate for my local test environment. > > 3) Various combinations of RES_OPTIONS in both the connman NTP plugin as > well as in ntpd_intres itself. > > 4) Ran connmand with --nodnsproxy. > > 5) Tried names that resolve against multiple addresses vs. names that > resolve against a single address. > > 6) Tried various combinations of 'hosts: ...' in /etc/nsswitch.conf. > > 7) Ran with / without avahi-daemon. > > 8) Tried ntp-4.2.7p156 (it segfaults). > > 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. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
