On Feb 26, 2014, at 10:09 AM, Michal Jaegermann <mic...@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 -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
