On 21/12/2023 19:38, Greg Wooledge wrote:
On Thu, Dec 21, 2023 at 06:08:26AM +0000, Albretch Mueller wrote:
Why is it I am noticing a 14 seconds difference on my computer
(booted with a Debian Live DVD)?
Have you executed any commands setting time since boot? Does the
difference remain after reboot?
$ 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.
You may try to pull more NTP-related info from timedatectl. I am unsure
if ntpsec is supported.
However, I also get "System clock synchronized: yes". I'm honestly
not sure what those two lines mean.
"NTPSynchronized shows whether the kernel reports the time as
synchronized (c.f. adjtimex(3))."
Hmm... let's try a brief experiment.
[...]
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/Chicago (CST, -0600)
unicorn:~$ timedatectl | grep -m1 zone
Time zone: America/New_York (EST, -0500)
[...]
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.
I have another guess. systemd-timedated is activated on demand and reads
/etc/localtime. It exits a half of a minute later. Perhaps second
command caused start of new process since the old one was dead already.
I do not think that it expect that something changes /etc/localtime
behind the scene. I admit inotify might be implemented, but expected way
is to call "timedatectl set-timezone ZONE".
