Red Hat Bugzilla – Bug 106572
bind-chroot doesn't install chroot's /etc/localtime, nor update it on tzdata updates
Last modified: 2007-11-30 17:10:32 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031003 Description of problem: /var/log/messages entries issued by a chrooted bind are in UTC, not in the local timezone, but they don't say so. This can be very confusing. Version-Release number of selected component (if applicable): bind-chroot-9.2.2.P3-4 How reproducible: Always Steps to Reproduce: 1.Start bind in the chroot 2.Look at /var/log/messages Actual Results: Messages will not be in the local timezone, without any indication of being in UTC. Expected Results: They should be in the local timezone. Additional info: Copying /etc/localtime to the chroot should be enough to fix this.
Fixed in bind-9_2_2_P3-6 Dan
I don't see any change in behavior. /etc/localtime is not present in the chroot, and messages are still logged with the wrong timezone.
Still present in -9
This works on my machine. Please make sure you uninstall bind-chroot and reinstall it. Since there is now a check to make sure files only get moved the first time bind-chroot gets installed. Dan
Aha, the uninstall&reinstall bit was what I was missing. This fixes the problem, indeed. Ideally, there should be some trigger on tzdata updates to copy the file again, should it change. tzdata should itself update /etc/localtime on postinstall, but currently it doesn't.
So this bug is closed correct? Dan
Hmm... Maybe I should have closed this bug and opened a new one about the tzdata trigger, instead of changing the summary?
tzdata cannot depend on shell etc. as it is a dependency loop. So I think the trigger needs to go into some other packages. What about redhat-config-date? That is a package which normally modifies /etc/localtime...
This bug should remain open against bind, since bind should eventually be changed when tzdata is adjusted, at which point bug 107507, that this bug depends on, will remind us.
/var/named/chroot/etc/localtime is not there after an everything FC2 install from scratch.
Hi, why don't you know how to debug? # rpm -ivvh bind-chroot-9.2.3-13.i386.rpm D: ============== bind-chroot-9.2.3-13.i386.rpm (snip) D: install: %post(bind-chroot-9.2.3-13) execv(/bin/sh) pid 2501 + test -r /etc/sysconfig/named + grep -q '^ROOTDIR=' /etc/sysconfig/named + echo ROOTDIR=/var/named/chroot + '[' '!' -d /var/tmp ']' (snip) It was easy to find out the reason of this BUG. The patch which fixes this BUG is below. --- bind.spec 2004/08/04 15:31:39 1.1 +++ bind.spec 2004/08/04 15:32:11 @@ -101,7 +101,7 @@ then : else echo ROOTDIR="%{prefix}" >>/etc/sysconfig/named -if [ ! -d "${prefix}/var/tmp" ]; then +if [ ! -d "%{prefix}/var/tmp" ]; then mkdir -m770 -p "%{prefix}/var/tmp" rm -f "%{prefix}/dev/null" mknod "%{prefix}/dev/null" c 1 3
This was fixed in bind-9.2.4rc6-3 . Next version (bind-9.2.4rc6-4) will make the chroot /etc/localtime a hard link to /etc/localtime instead of copying. Will ensure tzdata updates /etc/localtime.
It does copy /etc/localtime to /var/named/chroot/etc at install time, indeed, but AFAICT it still fails to update the copy of /etc/localtime in the chroot after a tzdata update (or anything else) that updates it. How was it supposed to update /etc/localtime in the chroot after, say, a tzdata update that modifies /etc/localtime?
And it gets worse: apparently, at the time we run the bind-chroot %post script at install time (anaconda), /etc/localtime in /mnt/sysimage is America/New_York, regardless of the timezone selected in the installer. Only at the end of the install is /etc/localtime set up according to the user selection, so /var/named/chroot/etc/localtime is always wrong unless you happen to be in America/New_York timezone.
Filed the above as bug 132385.
I'll fix by checking if /etc/localtime has changed in the named initscript and copying it again if so; this will handle timezone updates as well as initial install - this should be fixed in: bind-9.2.4rc7-14
*** Bug 132385 has been marked as a duplicate of this bug. ***
This is now fixed in bind-9.2.4rc8-14 (fc3-head).