heftig/rtkit

messages from syslog() are GMT instead of local time after doing chroot()

Opened this issue · 5 comments

Once the rtkit-daemon does chroot("/proc") it no longer has access to /etc/localtime, and so all time functions revert to localtime. Any calls to syslog() after this are logged (to /var/log/messages, in my case using syslog-ng) with the UTC time, but still shown with the local timezone (EST in my case.) For example
2020-11-18T00:03:33-05:00 localhost rtkit-daemon[26230]: Supervising 1 threads of 1 processes of 1 users.
was actually logged at
2020-11-17T19:03:33-05:00
which could also be
2020-11-18T00:03:33+00:00

I don't fully understand exactly where the problem lies, but my best understanding is that after doing the chroot, syslog() gets the timestamp of the message in UTC, but somehow only the time itself, without any TZ information, is being passed on to syslogd (or syslog-ng). I've been trying to figure out how to reset the TZ information after the chroot() but have not had any success finding the right incantation to make the time gods happy.

So - I don't think this is directly a bug in rtkit, but it would be nice it there was a way to get the messages logged so they don't look like they are hours off (depending on the distance from localtime to GMT.)

fixtimezone.txt Farily minimal patch (named .txt to allow upload)
Just before doing the chroot, it takes the current timezone and gmt offset to create a string (for me EST+5) which is then used after doing the chroot to set TZ in the environment. I believe it should work in any timezone. Note, however, that it just uses the current timezone at the time it is run, so theoretically, it could end up still being an hour off if it is not restarted when daylight time starts or ends.

I'm not sure if I should wait for someone else to test it, or just submit it as a PR?

was this ever applied?

I never heard anything about it.

do you still see the problem? i do

I don't see it, because I have the patch applied locally. (I run Gentoo, so everything is compiled from source, and adding a patch is pretty easy.) If the source already contained the patch, I'd get an error about that. I'm running 0.13-r1, where the r1 implies some Gentoo revision. I'd have to dig a bit to see what that includes.