| 1 |
On 2020.11.15 19:02, Jack wrote: |
| 2 |
> As usual, I've got what seems to be a really obscure problem, and I |
| 3 |
> have not found any reference to it searching the interwebs. |
| 4 |
> |
| 5 |
> The suspect package is sys-auth/rtkit-0/13-r1 (which has nothing to |
| 6 |
> do with chkrootkit) and I'm using app-admin/syslog-ng-3.26.1-r1. |
| 7 |
> |
| 8 |
> As a typical example from /var/log/messages (extract, and having |
| 9 |
> reconfigured syslog-ng to us iso timestamps) |
| 10 |
> |
| 11 |
> 2020-11-15T18:30:01-05:00 localhost CROND[7320]: (root) CMD |
| 12 |
> (/usr/lib/sa/sa1 1 1) |
| 13 |
> 2020-11-15T23:34:10-05:00 localhost rtkit-daemon[6263]: Supervising 0 |
| 14 |
> threads of 0 processes of 0 users. |
| 15 |
> 2020-11-15T23:36:38-05:00 localhost rtkit-daemon[6263]: Supervising 0 |
| 16 |
> threads of 0 processes of 0 users. |
| 17 |
> 2020-11-15T18:40:01-05:00 localhost CROND[15943]: (root) CMD (test -x |
| 18 |
> /usr/sbin/run-crons && /usr/sbin/run-crons) |
| 19 |
> |
| 20 |
> All rtkit messages to syslog seem to be in UTC, or at least five |
| 21 |
> hours off from my local Americas/New York timezone. rtkit uses the |
| 22 |
> syslog() call for all logging, and there is nothing in those calls |
| 23 |
> that even mentions timezone. |
| 24 |
> |
| 25 |
> However, in digging further, I found two log entries from rtkit which |
| 26 |
> do appear to be using local time. In looking at the rtkit source, |
| 27 |
> those two use the LOG_INFO and LOG_NOTICE as their levels. All other |
| 28 |
> logging in rtkit uses LOG_ERR, LOG_DEBUG, or LOG_WARNING, with one |
| 29 |
> exception: I see one LOG_INFO message (repeated, scattered across |
| 30 |
> the log) which does show the UTC time. |
| 31 |
> |
| 32 |
> So, does anyone have an idea what is going on? |
| 33 |
> |
| 34 |
> I have one theory so far, but I a bit stuck on how to test it. I'm |
| 35 |
> not sure where in the boot process rtkit gets started, but I think |
| 36 |
> it's automatically started when Dbus starts. As part of the daemon's |
| 37 |
> startup routine, it drops some privileges. Is it possible that the |
| 38 |
> applicable timezone gets changed when it drops privileges? As far as |
| 39 |
> I can tell, the log messages with the correct time are all produced |
| 40 |
> before it drops privs. Am I barking up the right tree, or am I |
| 41 |
> barking mad? |
| 42 |
|
| 43 |
I've done some more digging, with lots of debugging output. Up to a |
| 44 |
point, the process acknowledges the local timezone. However, after |
| 45 |
doing a 'chroot "/proc"' and then 'chdir "/"' it thinks it's UTC. |
| 46 |
Still doesn't make any sense to me, though. |
Archives