On Feb 26, 2014, at 10:09 AM, Michal Jaegermann <michal(a)harddata.com> wrote:
On Wed, Feb 26, 2014 at 10:39:34AM +0100, Miroslav Lichvar wrote:
> On Tue, Feb 25, 2014 at 10:27:56AM -0700, Michal Jaegermann wrote:
>> Searching through an output of journalctl when time was messed up
>> turns out to be not that obvious and I may missed some clues.
>
> Ok, it looks like something else than ntpd or chronyd is indeed
> setting the clock on your system.
So far this happened once for both affected installations. From that
moment I am trying to watch closely for these time warps and so far
nothing new of that kind. So this is "a weird set" instead of
"setting".
> As a quick check, does the following command print anything beside
> systemd and chronyd/ntpd?
>
> # for i in /proc/*/exe; do readelf -s $i 2>/dev/null | grep -q
'clock_settime\|settimeofday\|adjtimex' && readlink $i; done
That, slightly modified to print process identifiers too, prints:
/proc/10819/exe /usr/lib/systemd/systemd
/proc/10823/exe /usr/lib/systemd/systemd
/proc/13711/exe /usr/lib/systemd/systemd
/proc/13716/exe /usr/lib/systemd/systemd
/proc/1920/exe /usr/lib/systemd/systemd
/proc/1937/exe /usr/lib/systemd/systemd
/proc/1/exe /usr/lib/systemd/systemd
/proc/503/exe /usr/sbin/chronyd
Apart of init and chronyd these are process pairs like:
1920 ? Ss 0:00 /usr/lib/systemd/systemd --user
1937 ? S 0:00 \_ (sd-pam)
(this one owned by 'gdm').
Not sure how "interesting" that may be. Hm, looking at this systemd
leaves behind such pairs for users who were logged in at some moment
but already logged out. Possibly not related but this does not look
right. I better make a note in bugzilla.
You could also take what you have learned so far to the systemd list, they're fairly
responsive. You could ask if it's worth setting 'systemd.log_level=debug
systemd.log_target=console' as a persistent boot parameter in case this problem
happens again, since it's the highest level logger (debug logging in chronyd or ntpd
may not catch the culprit). The systemd debug might be too aggressive is why I suggest
asking.
systemd can actually set time via timedatectl however on its own it's not responsible
for setting time.
Chris Murphy