Simon Kelley <[email protected]> writes: > Ferenc Wagner wrote: > >> Is the a way to ensure that the dhcp-script can resolve the newly issued >> lease? (Of course it isn't a problem for the script itself, but for a >> stubborn program started from it, which does two-way DNS resolution just >> to make sure.) It seems to be racy, sometimes it works, sometimes it >> does not... I think the script invocation should be moved after >> registering the new lease in the DNS database. Or maybe the problem is >> something else entirely. > > Quickly checking the code, the DNS system gets updated long before the > script could possibly be run. "Something else entirely" looks a distinct > possibility.
Yeah, the following log excerpt shows that the dhcp-script called new_sge_client could resolve 10.250.1.88 perfectly well, but another program (qconf from SGE) called from it later failed that (last, tagless line) without even making a query: dnsmasq-dhcp: DHCPDISCOVER(br-alma-g) 52:54:00:12:34:56 dnsmasq-dhcp: DHCPOFFER(br-alma-g) 10.250.1.88 52:54:00:12:34:56 dnsmasq-dhcp: DHCPREQUEST(br-alma-g) 10.250.1.88 52:54:00:12:34:56 dnsmasq-dhcp: DHCPACK(br-alma-g) 10.250.1.88 52:54:00:12:34:56 52-54-00-12-34-56 new_sge_client: root: del 52:54:00:12:34:56 169.254.1.89 52-54-00-12-34-56 new_sge_client: root: add 52:54:00:12:34:56 10.250.1.88 52-54-00-12-34-56 dnsmasq: query[PTR] 88.1.250.10.in-addr.arpa from 127.0.0.1 dnsmasq: DHCP 10.250.1.88 is 52-54-00-12-34-56.alma.grid new_sge_client: 10.250.1.88 52-54-00-12-34-56.alma.grid unable to resolve host "10.250.1.88" I'm stumped. Maybe it's time to pull out the big-hammer strace... -- Thanks, Feri.
