[ntp:questions] ntpd deletes IPv6 interface after startup
kardel at ntp.org
Sun Nov 11 19:45:07 UTC 2007
Hi Hauke !
Hauke Lampe wrote:
> Frank Kardel schrieb:
> I did a bit more research for a bug report.
Thanks for digging into that.
> Due to a bug in my debugging output (d'Oh!), ntpd appeared to use
> getifaddrs while in fact it used ifiter_ioctl. As I understand it, glibc's
> getifaddrs() supports only IPv4 and libinet6 is not available on my system.
> By alternating configuration options, I found that the problem manifests
> only when ntpd chroots itself. I usually start ntpd with
> -u ntpd:ntpd -i /var/lib/ntp
> to chroot and drop root privileges after startup. Without the -i option,
> ntpd binds to all interfaces and keeps listening, whether or not it changes
> UID to user ntpd.
> After chroot, /proc/net/if_inet6 isn't available to ifiter_ioctl anymore.
> So, I don't think it's a real bug, although an unexpected nuisance.
Workarounds in the base code for all these environment induced OS API
behavior changes would be hard.
> The options AFAIK see, are:
> - change ifiter_ioctl to enumerate IPv6 interfaces through a socket call as
> it does for IPv4. I don't know if that's even possible.
> - install libinet6 to enable getifaddrs(). This looks possible, but I'm not
> sure I really want to go there
The problem would be that the API interface used is determined at
configure time - not at run time.
> - don't use chroot
> - mount proc on /var/lib/ntp/proc
I think that would be a viable option - recreate the original
environment. There may be security hazards though.
> - keep running with -U 0
That's the simplest solution if you are running in a static address
> I'll stick with -U 0 for now as it doesn't seem to do any harm, even after
> I shut an interface down and brought it up again.
Keep in mind that ntpd sticks to the interface list it found at startup
It will not discover any interface changes in the -U 0 mode. If it would
be forced to do so (e.g. ntpdc -c ifreload) it would drop the IPv6
> Should I still file this as a bug?
Chances to fix Linux glibc/proc features in the base code are slim.
> I added a note to
That is a good action. Thanks for documenting that.
More information about the questions