Hi Anand,
Never mind. I understand your situation.
Initially, we had just timestamps in zone dumps. I prefer this, since
it makes smaller dumps and it is faster to process such records.
Afterwards,
we turned it off due to incompatibility with Bind. Because Bind is
unable
to load these dumps if you need it.
Is there still anybody who requires human-readable timestamps in zone
dumps from Knot?
If not, we probably disable this functionality.
Thanks,
Dan
On 2014-01-10 23:08, Anand Buddhdev wrote:
On 10/01/2014 19:42, daniel.salzman(a)nic.cz wrote:
We have probably found the problem. The function
gmtime, which we use,
is not thread safe. So I have replaced it with a better one. Please,
try the attached patch.
Hi Daniel,
Thanks for this. However, I prefer not to test this on our current Knot
servers, as they are running in production. I have applied Marek's
earlier patch which disabled human-readable timestamps, and that's
keeping this problem away.
Actually, I even asked Marek why you convert the timestamps to
human-readable in the zone dumps. After all, the zone files are only
going to be read back in by Knot, so you'd save some cycles when
writing
and reading the zones, by not converting them back and forth between
human-readable and unix timestamp.
Is it reasonable to ask that you just dispense with human-readable
timestamps?
Regards,
Anand