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.
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.
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.
(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
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.
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