[rbldnsd] rbldnsd logging in varying timezones ?

[Michael Tokarev]

[Replying to more than a month old email]

Michael Tokarev wrote:
> Per Jessen wrote:
[wrong timestamps in syslog after chroot, with glibc-2.4]

> Oh well.  I'll set up glibc-2.4 here and see what's it all about,
> in a few days.

Ok,  More than a month has passed, but I can't reproduce the
issue.  I've even installed current suse glibc here, -- nope,
it displays all the timestamps correctly, both before and after
chrooting.

Really nothing has changed in rbldnsd in this area, for a very
long time.  The whole time stuff is the only one I know -- call
tzset() before chroot(), to force time-related libc functions
to read/parse current timezone information into memory, so that
no access to timezone data will be required.  Glibc (and - I
think - other libcs) does not provide anything else for that
purpose, and a call to tzset() is the one to do in such a
situation (when chrooting).

It's umm.. strange.  Yes, glibc tries to be smarter and tries
to update its view of timezone information when it detects
a change in /etc/localtime file (or whatever), even after the
call to tzset() (well, I think nothing forbids it from doing
so anyway).  But why it loses its idea of current timezone
when it is unable to read /etc/localtime (because there's no
such file in chroot jail, and should not be), and, most
important, how it does it - I have no idea.  Really.  I studied
the source code of glibc, and it *looks* like it should cope
with all that stuff just fine - can't re-open /etc/localtime,
so use current in-memory copy, don't drop it.  That's what
the code does, at least it seems so.

Is it something specific to your single machine, or does any
suse linux machine behaves this way?  I can definitely say
that, for example, on debian and redhat, many versions, it
works correctly.  Also on several versions of solaris and
freebsd...

In any way, the problem is NOT in rbldnsd.  It's in glibc.
The sequence:

  tzset()
  chroot(...)
  do_something_timezone-related()

is the real and only way to ensure we will not access non-
existing timezone information after chrooting().  This is
portable.  So if in your case this standard sequence does
not work, and the only other piece of software involved is
glibc, it must be a bug in glibc somewhere.


<rant>
Can someone tell me, why the hell this idiotic syslog()
routine passes current time information to LOCAL syslog
daemon, who is pretty much capable to determine the current
time by its own?  Note that "current time" is something
quite.. undeterministic, because it obviously depends on
the timezone (it's funny at best to see in your syslogs
records for "now" inermixed with records for several hours
back AND records for several hours in the future - when
your machine gets accesses from different places of the
world by different users, each having their own $TZ, and
running their own software), AND, more, it depends on
urrent.. LOCALE!  Timestamps in system logs in different
LANGUAGES!

Syslogd should receive priority and message text, and should
append timestamps by its own.  In fact, this is what it
actually DOES, if it thinks (applying some "heuristics",
so to say) the message text does not contain the timestamp --
by checking that, in message it received, like:
  Jul 15 00:49:10 rbldnsd[2292]: stats for...
  0123456789012345...
in positions 3,6, and 15 there are spaces, and in posi-
tions 19 and 22 there are colons (:), and digits on some
other places.

That all to say: its not the damn application's business
to tell syslog which timestamp to write to the logfile.
Especially it's interesting for "0wned" application.
Syslog knows pretty well when the message has been
generated.  And it works with default system language
and timezone settings.  And it's it who should generate
the timestamps.
</rant>

Thanks, it's much better now.

Seriously.  This and other similar issues (several outlined
above in "rant", one is with chroot - the current one) are
all moot.  Because the real bug is how libc's syslog() routine
works.  This is historical: many years ago someone didn't
think enouth when writing first syslog daemon and routines.
Now, syslogs are prett much capable to correct the mistake,
but libc still thinks it has to deal with very old syslogd...

And it should be solved there.  Once and for all.

Btw, I wrote about this all to glibc mailing list - if memory
serves me right - at 1998, or even 1996...  Still waiting for
reply... ;)

/mjt