Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
genterminl opened this issue Nov 18, 2020 · 5 comments

Comments

@genterminl
Copy link

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.)

@genterminl
Copy link
Author

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?

@LargePrime
Copy link

was this ever applied?

@genterminl
Copy link
Author

I never heard anything about it.

@LargePrime
Copy link

do you still see the problem? i do

@genterminl
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants