Bug 444043 - timezone is kind of incompatible with chroot
timezone is kind of incompatible with chroot
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-24 14:42 EDT by Lennart Poettering
Modified: 2008-06-06 08:45 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-06 08:45:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lennart Poettering 2008-04-24 14:42:31 EDT
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 07:04:47 EDT
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 12:58:31 EDT
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 13:35:52 EDT
(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 10:21:04 EDT
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 06:06:08 EDT
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

Note You need to log in before you can comment on or make changes to this bug.