Hello Willy, Le 14/03/2016 08:45, Willy Tarreau a écrit : > Hi Benoit, > > On Mon, Mar 14, 2016 at 08:32:35AM +0100, Benoît GARNIER wrote: >> Hello Willy, >> >> Le 13/03/2016 23:49, Willy Tarreau a écrit : >>> Hi Benoit, >>> >>> On Sat, Mar 12, 2016 at 09:45:25AM +0100, Benoît GARNIER wrote: >>>> You just need to call tzset() once before chrooting to initialize the >>>> timezone subsystem. >>> Finally I did it directly in your patch, it was not worth delaying a >>> release for such a small change. >> I did not send the patch earlier because I was trying to gather some >> more informations about chroot() and local times. >> It seems that my patch would not play nicely with some versions of glibc >> and could introduce a subtle bug. >> >> Some time functions call tzset() internally. This is the case for >> strftime() or localtime() (but not localtime_r() or gettimeofday()). >> So when populating the GMT offset cache, a hidden call to tzset() is done. >> The issue is that some old glibc, when not finding /etc/localtime (this >> is the case after a chroot), would reset the timezone to GMT. >> Thus, the first log would have a localtime with a GMT offset (wrongly) >> set to +00:00, and subsequent logs would be in full GMT time. >> >> See the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=444043 > Interesting. > >> In this case the only solution is to copy /etc/localtime to >> <chroot>/etc/localtime. > Well, in the worst case it means we'll fall back to the previous behaviour > (I mean before your patch) if this happens, so that's not the end of the > world.
No really, the first log would have a localtime with a GMT offset, following logs would be in full GMT format. >> So, I was trying to elaborate on your previous suggestion: prepare the >> cache at startup, but without messing with the tm_isdst flag. > Since the libc doesn't seem well suited to these tricks, let's start the > simple way first and only contemplate alternatives if people still have > the problem, then we'll know what OS is affected and will be able to > contemplate some workarounds (one of them still being "cp"). Another more portable solution is to code an equivalent of strftime(..."%z"...) with no call to tzset(). We can get back to an GMT time and extract the GMT offset from that. It would be slow, but we'd only do this twice, once for each tm_isdst value. Anyway, this is what glibc reverts to when tm_gmtoff is not defined in struct tm. I think this is the most portable and less risky solution. > Thanks, > Willy > Benoit GARNIER
