On Thu, Dec 21, 2023 at 06:08:26AM +0000, Albretch Mueller wrote:
> and what would the systemd way to synch the RTC (Real Time Clock) and
> UTC?
I don't understand this question at all. The system clock value is
normally written to the RTC as a backup when the system shuts down.
Then, the RTC value is read at boot time to initialize the system clock.
> Why is it I am noticing a 14 seconds difference on my computer
> (booted with a Debian Live DVD)?
Because you're not networked? If the system has no time sources to draw
upon, other than its own battery-backed RTC, then it will continue to
drift farther and farther from the correct time.
> $ timedatectl
> Local time: Thu 2023-12-21 00:52:20 UTC
> Universal time: Thu 2023-12-21 00:52:20 UTC
> RTC time: Thu 2023-12-21 00:52:06
> Time zone: Etc/UTC (UTC, +0000)
> System clock synchronized: no
> NTP service: n/a
> RTC in local TZ: no
I don't think this command's output is accurate for systems using NTP
services that *aren't* systemd's. I'm running ntpsec on mine, and I
also get that same "NTP service: n/a" line.
However, I also get "System clock synchronized: yes". I'm honestly
not sure what those two lines mean. I don't know how far I would
trust this command, on systems that are not fully invested in the
systemd takeover.
Hmm... let's try a brief experiment.
unicorn:~$ sudo ln -sf /usr/share/zoneinfo/America/Chicago /etc/localtime
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/Chicago (CST, -0600)
unicorn:~$ sudo ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/Chicago (CST, -0600)
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/New_York (EST, -0500)
There was a fair bit of time elapsed between those last two commands,
as I was busy pasting things into this email. I don't know how long,
exactly. More than a second, but less than two minutes.
So... this is interesting. Apparently timedatectl doesn't simply look
at the target of /etc/localtime. There's a DELAY before the value is
correctly reported. This tells me that timedatectl is in communication
with some process (perhaps PID 1, I don't know), and this other process
only discovers that /etc/localtime has changed after some time has passed.
Is it *polling*? I have no idea, but that's what it looks like.
More and more reasons not to let systemd touch my clock. Not that I
needed more of them, but... here we stand.
