On 11/26/18 1:46 PM, Stephen Morris wrote: > On 21/11/18 10:02 am, Rick Stevens wrote: >> On 11/20/18 2:09 PM, Ed Greshko wrote: >>> On 11/21/18 5:07 AM, Stephen Morris wrote: >>>> >>>> Given that the front screen of the bios is displaying the time as >>>> local time, presumably >>>> that means that the time settings in the bios are local time and the >>>> motherboard bios >>>> doesn't provide any means to input the time as GMT, hence the bios >>>> is not set to GMT. >>> Let me try this one last time. And it will be one last time. I can >>> tell you how to set >>> your system up to get consistent log entries. It will be your choice >>> to do it or not. >>> >>> You have already said that the motherboard has no concept of time >>> zones. That is totally >>> irrelevant. YOU know what time it is and YOU know what time zone you >>> are in! >>> >>> I look at my mobile phone and see it is 05:55 on November 21. I know >>> I am in GMT+8. So, >>> GMT time is now 21:55 on November 20. So, I go to my BIOS screen and >>> enter 21:55 as the >>> time and November 20 as the date. The motherboard clock is NOW set >>> to GMT! It matter not >>> one lick if the MB has an idea of any time zone! >>> >>> Step one Done. >>> >>>> Thinking about the data as displayed by journalctl at boot time, the >>>> time stamp on the >>>> messages of Nov18 18:16 for a Nov 18 7am boot would make sense if >>>> the OS assumed the >>>> system clock was GMT and added the local zone offset to the time. >>>> >>>> Given the fact that my /etc/adjtime has local as the last line, and >>>> from my recollection >>>> I have not explicitly run the indicated commands that would set >>>> that, why is the OS not >>>> honouring that specification right from boot commencement? >>> Set that last line to UTC. You have now told the O/S that the HW >>> clock is set to >>> UTC/GMT. So now the O/S knows what you know. >>> >>> Step two Done. >>> >>> Make sure the the link /etc/localtime points to a correct time zone >>> for where your system >>> is physically located. >>> >>> [egreshko@meimei etc]$ ll /etc/localtime >>> lrwxrwxrwx. 1 root root 33 Dec 21 2017 /etc/localtime -> >>> ../usr/share/zoneinfo/Asia/Taipei >>> >>> for ME. >>> >>> (you can use timedatectl to show/set) >>> >>> Step three Done. >>> >>> Reboot >>> >>> Done. >>> >>> You will now get correct and consistent date/time stamps in your logs >>> going forwad. >>> Previous timestamps won't be fixed. Don't want to do that. Well, >>> you'll be in the same >>> situation you are now and that will be that. >>> >>> >>>> With the time zone data coming from the tzdata package, are you >>>> saying that each year >>>> when the local governments change when daylight saving starts and >>>> ends, that the tzdata >>>> package is updated to reflect that? >>> Look at the changelog for the package as I showed you. >>> >>> rpm -q --changelog tzdata >>> >>> and you will see the dates it was updated and why it was updated. >>> The answer to your >>> question is obvious. >> And to make it clear, Linux expects the SYSTEM clock to be in UTC, >> Windows expects it to be in local time. The SYSTEM clock is set to the >> BIOS clock at boot time for both OSes. There is really no (clean) way to >> make these two disparate things live together. There is a way to bugger >> Windows to use a UTC clock via a registry entry, but it's a kludge. >> Choose which one (Windows or Linux) is your primary OS, and set your >> BIOS clock accordingly (localtime for Windows, UTC for Linux). > > At the moment my main OS is Windows as I spend a fair amount of time > playing online games that can't be played under Linux, so I mainly only > boot to Linux for email processing, until such time as I decide to forgo > the gaming environment and get back into serious development work. I > haven't investigated recently the ability of VM's to provide the > necessary hardware graphics quality for gaming, but the last time I > looked at this possibility the graphics capabilities weren't up to scratch. > > Given that /etc/localtime seems to be a symbolic link to > /usr/share/zoneinfo, for the same reasons that /etc may not be mounted > /usr may also not be mounted, so how does the boot system know what > offset to add to the bios time to reach local time? At boot time (when the logging starts), the system uses the hardware clock to set the system clock, so all logs will be based on what the hardware clock was set to (and the assumption is that it's UTC). All log entries are stamped with the system clock value. Later, once /etc and /usr are mounted, the logger NOW knows what your local timezone is and the log entries will be DISPLAYED in your local timezone. The log entries themselves (in the database) still are being tagged with the system clock value. Later on, chronyd drags the system clock into sync with UTC and the log entries from then on have the correct UTC timestamp. However, they are still displayed in your local timezone. journalctl has no idea when the timestamps changed, so log entries made before chronyd did its thing will be displayed with the wrong timestamp. >> Linux will handle a localtime BIOS clock better. If your BIOS clock is >> in local time (as Windows wants) and you boot Linux, the log entries >> will have the incorrect time until chronyd drags the SYSTEM clock into >> sync with UTC. The log entries will be correct from that point onwards. >> >> So, use journalctl to look for log entries for chronyd: >> >> journalctl -b -u chronyd >> >> And look for the lines that indicate the clock was reset: >> >> <datestamp> <hostname> chronyd<[pid]>: System clock was >> stepped by <some-number> seconds > > I've issued the command above and the last message displayed says that > the 'System clock TAI was stepped by 37 seconds', the first two messages > displayed, both with the same timestamp were 'Starting NTP client > server' and 'cronyd version 3.14 starting'. The thing that was > interesting about all the messages displayed by the journalctl command > was that the timestamp on all the messages was local time, which I > assume means that the system clock was running in local time before > cronyd was started? Well, there are several things. You can think of it like that. If you look closely, that the entries after that "stepped by" will be 37 seconds different than those before the "stepped by" entry. Again, there really are two clocks. One, the hardware clock, is powered by that little button battery on your mobo and runs continuously. The second clock is the system clock and it's maintained by the operating system. The hardware clock is used to set the system clock at boot time and it's essentially ignored the rest of the time. This is true for both Windows and Linux. The main difference is that Windows expects the system clock to be in local time and Linux expects the system clock to be in UTC. Now, if your hardware clock is set to local time, your system clock is also (initially) in local time and log entries are stamped with that clock value. Regardless, journalctl will display things using your timezone but it assumes the raw data in the database is stamped with a UTC-based system clock. This explains why the times look wrong at this point in the logs. Once the system can determine what your timezone actually is and that your hardware clock is in local time (the last line of /etc/adjtime says "LOCAL" and not "UTC"), then it may do the computation for you and reset your system clock to UTC so things make sense. I won't swear to that as I haven't really walked down that fork of the initialization tree, but it seems logical. From this point, log entries will appear to be correct, although they may not be super accurate as hardware clocks are often inaccurate, so the initial setting of the system clock may not be accurate. If all that's true, then doing "journalctl -b 0" will show a big timeshift at some point--things before that point will be using the (incorrect) localtime-based system clock, things after it will be using the UTC-based system clock. journalctl has no idea when the clock got buggered and assumes all entries are UTC-based, hence the apparent time shift. A second, smaller time jump will appear once chronyd actually syncs the system clock to true UTC (indicated by that "stepped by" bit in the logs). Once that happens, then log entries will be accurate from that point onwards and chronyd will do its best to keep the system clock synced to UTC. Keep in mind that journalctl will assume ALL log entries have a UTC timestamp, regardless of when the clocks got mangled and this is the cause of the time shifts in the display. The radical change in system clock when it switches from local time to UTC time MAY cause programs to malfunction, since they assume that the system clock was in UTC. This _may_ be why your VPN was disconnecting...it assumed there was no traffic for whatever the difference is between your local time and UTC, so it disconnects. Note that the hardware clock will remain in local time so all this stuff has to happen again whenever you boot Linux unless you do something like "hwclock -w" to set the hardware clock to the (now UTC) system clock. Windows won't like that. :-) Always remember that the timezone stuff is only used for user interaction (displaying things, setting things, interpreting crontabs, etc.). All internal timestamps (log entries, even the atime, ctime and mtime values on files) are based on the system clock, which is expected to be in UTC (for Linux). If your primary OS is Windows, then by all means keep the hardware clock in local time. Just be aware that Linux logs (and some programs) may be confused until the system clock becomes UTC-based and synced to UTC during startup when you boot Linux. Then everything should be stable. Time: It's all relative. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks@xxxxxxxxxxxxxx - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - Death is nature's way of dropping carrier - ---------------------------------------------------------------------- _______________________________________________ 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
