The chroot environment is not created correctly. The etc directory ends up outside the chroot as chrootetc. emerge --debug --verbose --config openntpd [...] + rm -f //var/lib/openntpd/chrootetc/localtime + mkdir -p //var/lib/openntpd/chrootetc + ln /etc/localtime //var/lib/openntpd/chrootetc/localtime + chown -R root:root //var/lib/openntpd/chroot [...] In the ebuild, in pkg_config and pkg_postrm: "${EROOT}${NTP_HOME}"etc should be "${EROOT}${NTP_HOME}"/etc Also, would it be correct to use "${EROOT%/}${NTP_HOME}" to avoid the double slash?
The thing, which really wonders me is, why isn't ntpd complaining about the missing /etc/localtime in it's chroot environment?
Hmm, ntpd doesn't care if it's there, but if it's not, all of the syslog entries it generates could be timestamped in GMT rather than the local time zone. Making a hard link will fail if / and /var aren't on the same filesystem, so it's not really a good approach anyway. I vaguely remember having this discussion before in another bug? Maybe it was for a different package. I think the cleanest thing to do would be have the init script startup check to see if the chroot localtime is different than the system localtime, and if so, copy the system localtime into the chroot. Another option would just be to set the TZ environment variable in the init script from the /etc/timezone file, ntpd wouldn't need a copy of localtime if the time zone is explicitly set. Hmm again, I just whacked localtime from my ntpd chroot and logs still have the right date. It looks like ntpd calls openlog before it chroots, so even without a localtime in the chroot the logs have the right timestamp. I can't think of any reason other than log timestamps ntpd would need to know about the timezone. Why did we start copying localtime into the chroot in the first place? Just general principle, or solving a specific issue? I think the simplest solution here is to just stop worrying about having a localtime in the chroot, unless somebody can point to why it's needed.
(In reply to Paul B. Henson from comment #2) > Hmm, ntpd doesn't care if it's there, but if it's not, all of the syslog > entries it generates could be timestamped in GMT rather than the local time > zone. > > Making a hard link will fail if / and /var aren't on the same filesystem, so > it's not really a good approach anyway. We need some solution, which works with systemd and openrc. > Solution 1.) > I vaguely remember having this discussion before in another bug? Maybe it > was for a different package. I think the cleanest thing to do would be have > the init script startup check to see if the chroot localtime is different > than the system localtime, and if so, copy the system localtime into the > chroot. > Solution 2.) > Another option would just be to set the TZ environment variable in the init > script from the /etc/timezone file, ntpd wouldn't need a copy of localtime > if the time zone is explicitly set. > > Hmm again, I just whacked localtime from my ntpd chroot and logs still have > the right date. > Solution 3.) > It looks like ntpd calls openlog before it chroots, so even without a > localtime in the chroot the logs have the right timestamp. I can't think of > any reason other than log timestamps ntpd would need to know about the > timezone. Why did we start copying localtime into the chroot in the first > place? Just general principle, or solving a specific issue? I think the > simplest solution here is to just stop worrying about having a localtime in > the chroot, unless somebody can point to why it's needed. This stuff was already there when I took over the package, so I am not sure if it is actually needed. Bug #226491 seems to be part of the reason. But if localtime isn't needed in chroot, Solution 3.) seems to be the easiest.
Created attachment 375102 [details, diff] patch against gx86 version Patch to fix the original issue.
I agree. It looks as if it was introduced to fix bug #226491. However, that no longer seems to be an issue. At least I'm not able to reproduce it. Perhaps it was fixed upstream. I had a look at the openntpd code. The root owned process calls tzset() early on, before forking the ntp owned child that runs in the chroot. That should read /etc/localtime, and set up tzname for use in other time conversion functions. That means /etc/localtime should not be necessary. Still - perhaps the safest thing is to keep localtime for now. Maybe one could test without it in a more controlled fashion by removing it in an unstable ebuild.
I guess it doesn't hurt anything for it to be there, other than the install will generate noise when the hard link fails, so this patch looks good to me for now. I took a quick look at the diffs between 3.9 and the current version, and nothing jumped out as being a fix for this. Maybe something at the OS or glibc level changed since then? Dunno. Without knowing exactly why it's working now and why it wasn't before it might be safer to just keep copying it into the chroot.
+*openntpd-20080406-r8 (16 Apr 2014) + + 16 Apr 2014; Christoph Junghans <ottxor@gentoo.org> + +openntpd-20080406-r8.ebuild: + fixed setup of localtime in chroot (bug #506970) +
