Frank Kardel schrieb: > Have you checked via ifconfig -a that the interface are still listed > when ifiter fails to enumerate them ?
Yes, the interface state has not changed since the last reboot. It's up and reachable from the outside. > Please file a bug at http://bugs.ntp.org. Be sure to include detailed > information about your operating system. I did a bit more research for a bug report. 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. 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 - don't use chroot - mount proc on /var/lib/ntp/proc - keep running with -U 0 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. Should I still file this as a bug? I added a note to http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.3.2.5.1. Hauke. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
