Hi Willy,
Le 14/03/2016 20:40, Willy Tarreau a écrit :
>> Anyway, older version of strftime() also used to call tzset() (or an
>> internal variant), that's why I'm very nervous about my previous patch
>> used inside a chroot().
> Got it, thanks for the explanation. So now all what matters is to know
> whether there are people running haproxy with the %Tl log tag (added in
> 2012) on distros that ship an older glibc. Simply stated, we'll see, and
> if that breaks we can easily revert it. We try as much as possible to be
> regression-free but we don't always succeed and it happened a few times
> already that a fix broke something.
Good point, but I don't know the status of chroot()+strftime() on
non-linux platforms.
>>>> 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.
>>> Doesn't this bring us back to the initial principle of caching the offset
>>> for each possible value ?
>> Yes, it's the current patch but basically replacing strftime(..."%z"...)
>> by mktime()+gmtime_r()+tm_diff().
>> Please note that this will be done only twice, to populate the cache on
>> demand. After all, we're just trying to get a time offset from GMT, so
>> why not retrieving GMT time and computing a simple difference?
> That was my first proposal, to have one offset per DST computed before
> chrooting :-)
No, here I meant to compute on demand the needed offsets at runtime (as
I did in my patch), because at that time we have valid date/is_dst
combinations.
Anyway, that was a nice try, but a very bad idea: even if not stated in
the man page, mktime() calls tzset() and resets the timezone to GMT if
it cannot open /etc/localtime.
I could skip the mktime() part, but the interface would be ugly, I would
have to pass both time_t and the matching local struct tm at the same
time to the function.
So this solution can be eliminated now. I'm in the situation where I
don't have any elegant solution for older systems.
> Don't worry. I've released all pending versions yesterday evening, there
> were several much more serious issues that were causing trouble to users
> and needed to be fixed, so we'll queue your next fix for next releases.
> Take your time, as I said in the worst case if someone faces a problem we
> can simply revert your fix, there's no real problem with that as long as
> you don't feel offended by a revert of course (I probably have the record
> of number of reverts).
Well, no, I won't be offended if you revert my previous patch.
It fixed a bug, but if it introduces a regression it should be reverted
since I have no real solution for now.
It's up to you, such is the life of a BDFL! :-)
> Willy
Benoit GARNIER
Le 14/03/2016 20:40, Willy Tarreau a écrit :
>> Anyway, older version of strftime() also used to call tzset() (or an
>> internal variant), that's why I'm very nervous about my previous patch
>> used inside a chroot().
> Got it, thanks for the explanation. So now all what matters is to know
> whether there are people running haproxy with the %Tl log tag (added in
> 2012) on distros that ship an older glibc. Simply stated, we'll see, and
> if that breaks we can easily revert it. We try as much as possible to be
> regression-free but we don't always succeed and it happened a few times
> already that a fix broke something.
Good point, but I don't know the status of chroot()+strftime() on
non-linux platforms.
>>>> 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.
>>> Doesn't this bring us back to the initial principle of caching the offset
>>> for each possible value ?
>> Yes, it's the current patch but basically replacing strftime(..."%z"...)
>> by mktime()+gmtime_r()+tm_diff().
>> Please note that this will be done only twice, to populate the cache on
>> demand. After all, we're just trying to get a time offset from GMT, so
>> why not retrieving GMT time and computing a simple difference?
> That was my first proposal, to have one offset per DST computed before
> chrooting :-)
No, here I meant to compute on demand the needed offsets at runtime (as
I did in my patch), because at that time we have valid date/is_dst
combinations.
Anyway, that was a nice try, but a very bad idea: even if not stated in
the man page, mktime() calls tzset() and resets the timezone to GMT if
it cannot open /etc/localtime.
I could skip the mktime() part, but the interface would be ugly, I would
have to pass both time_t and the matching local struct tm at the same
time to the function.
So this solution can be eliminated now. I'm in the situation where I
don't have any elegant solution for older systems.
> Don't worry. I've released all pending versions yesterday evening, there
> were several much more serious issues that were causing trouble to users
> and needed to be fixed, so we'll queue your next fix for next releases.
> Take your time, as I said in the worst case if someone faces a problem we
> can simply revert your fix, there's no real problem with that as long as
> you don't feel offended by a revert of course (I probably have the record
> of number of reverts).
Well, no, I won't be offended if you revert my previous patch.
It fixed a bug, but if it introduces a regression it should be reverted
since I have no real solution for now.
It's up to you, such is the life of a BDFL! :-)
> Willy
Benoit GARNIER