Bug 444043

Summary: timezone is kind of incompatible with chroot
Product: [Fedora] Fedora Reporter: Lennart Poettering <lpoetter>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: drepper
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-06 12:45:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lennart Poettering 2008-04-24 18:42:31 UTC
Right now, if a process chroot()'s itself to an empty directory and thus doesn't
have access to /etc/localtime anymore glibc will fall back to UTC for all timing
info. 

All syslog messages will thus bear a UTC timestamp. rsyslog will ignore the
timestamps for local messages and always stick in a timestamp in the real system
TZ. The problem is thus hidden most of the time.

However, if people enable network syslog or use some more exotic implementation
that honours the timestamp of all received msgs this does become a problem:
messages from chroot()s always come in UTC and since syslog msgs themselves
carry no timezone info this is difficult to fix for the receiver.

The usual fix is to copy /etc/localtime into the chroot before actually
chrooting. However, this is a bit ugly I would argue, and requires r/w
filesystems and free disk space, and so on and so on.

Thus I'd like to request some functionality in glibc that allows TZ info to be
cached if /etc/localtime is not available anymore, but previously (i.e. before
the chroot) was available.

Comment 1 Jakub Jelinek 2008-04-28 11:04:47 UTC
Even if we added some kind of deamon for the time zone, if you don't have
/etc/localtime copied into the chroot, then you wouldn't have a unix socket in
the chroot either through which it could communicate with the daemon.  It is
really not hard to ensure /etc/localtime is present and uptodate in the chroot,
or you can use TZ env var, at least for timezones where current rules can be
expressed in the POSIX syntax (most of them) - though that won't have accurate
historic data.

Comment 2 Lennart Poettering 2008-04-28 16:58:31 UTC
Daemon for time zone? Oh no. I think we have a misunderstanding here.

All I am asking for is that programs can call tzset() once before chrooting. And
this will read all timezone data. And then, when the tz data is used later on,
after the chroot, and no longer accessible the cached data will be used. The
current behaviour is to go to disk each time, and when the TZ data is not
accessible anymore glibc falls back to UTC.

Comment 3 Ulrich Drepper 2008-04-28 17:35:52 UTC
(In reply to comment #2)
> All I am asking for is that programs can call tzset() once before chrooting. And
> this will read all timezone data.

We already have such a program.  It's called 'cp'.

cp /etc/localtime /path/to/chroot/etc

If you want to allow changing the timezone also use

cp -r /usr/share/zoneinfo /path/to/chroot/usr/share

Comment 4 Lennart Poettering 2008-05-02 14:21:04 UTC
Yes, Ulrich, I know that. But if you'd had read my initial bug report you'd have
seen why I think that this solution is suboptimal.

Also it makes it quite a bit more difficult to get it right to dynamically set
up a new chroot environment, then change to it and drop priviliges from C daemons.

Comment 5 Bug Zapper 2008-05-14 10:06:08 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping