On 11/12/18 12:49 PM, Stephen Morris wrote: > On 9/11/18 8:28 pm, Patrick O'Callaghan wrote: >> On Fri, 2018-11-09 at 00:08 +0000, Rick Stevens wrote: >>> On 11/8/18 2:41 PM, Patrick O'Callaghan wrote: >>>> On Fri, 2018-11-09 at 08:02 +1100, Stephen Morris wrote: >>>>> how is linux using GMT when everything is running local. >>>> All Unix-based or Unix-derived systems, including Linux, use GMT >>>> internally, and have done since the very first versions back in the >>>> 70s. >>> Uhm, they _assume_ GMT on the hardware clock. There is no way for the >>> kernel to verify it's on GMT if it's isolated. >> Of course. That's what I mean. The GMT basis for all time measurement >> in *nix is hardwired. >> >>> NTP (chronyd, ntpd, >>> ntpdate, whatever) will force the clock to GMT, but if you don't run >>> NTP I can see very weird stuff on file dates and logs because the >>> kernel will assume GMT on the system and translate it to local time. >>> >>>> Even if you set your hardware clock to local time, the internal >>>> timestamps used for files will be stored as GMT and converted back when >>>> displayed, according to your timezone environment. This also applies to >>>> logs. >>> Which would explain any mondo weird timestamps in his log. I believe the >>> OP said there was a significant time jump in the log entries at some >>> point. I could see this if his clock isn't on GMT and was drug there >>> kicking and screaming by NTP. Logs produced before NTP got caught up >>> would assume the old, local hardware clock time (and be way off), then >>> the clock gets buggered by NTP and the log entries start making sense >>> from that point. >>> >>> This is all surmise on my part, of course. >> Yes, there is probably some interaction of that sort going on. > > So given all this, when searching journalctl for boot messages across > particular datetime ranges, how do you find them when the timestamps in > the journals are blatantly wrong, potentially up until the desktop loads? I don't believe it's when the desktop loads that changes the clock, but when chronyd resets it. But that doesn't help you much. I don't know what to tell you. You're trying to base a search on data that is inconsistent. My guess is you'd need to do two searches, one for the time the clock gets caught up, then adjust your next search to whether you think the event was before or after that time. For example: [root@prophead ~]# journalctl -b -u chronyd -- Logs begin at Thu 2016-06-23 10:06:25 PDT, end at Mon 2018-11-12 13:27:11 PST. -- Oct 22 09:39:45 prophead.alldigital.net systemd[1]: Starting NTP client/server... Oct 22 09:39:46 prophead.alldigital.net chronyd[1062]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVD> Oct 22 09:39:46 prophead.alldigital.net chronyd[1062]: Frequency 13.721 +/- 0.032 ppm read from /var/lib/chrony/drift Oct 22 09:39:53 prophead.alldigital.net systemd[1]: Started NTP client/server. Oct 22 09:40:44 prophead.alldigital.net chronyd[1062]: Selected source (redacted) Oct 22 09:40:44 prophead.alldigital.net chronyd[1062]: System clock wrong by 29.498546 seconds, adjustment started Oct 22 09:41:13 prophead.alldigital.net chronyd[1062]: System clock was stepped by 29.498546 seconds You can see there that the journal was plugging along, then at 9:40:44 the system noticed the clock was about 30 seconds slow, so it poked it and the clock entries changed from 09:40:44 to 09:41:13, just about 29 seconds forward. So, prior to 09:40:44, I'd use that as my search and after that point, things should be synced to the real time. Not much help, but....... ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Blessed be the peacekeepers, for they shall be shot at from - - both sides. - - -- A.M. Greeley - ---------------------------------------------------------------------- _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
