On 12/21/23, Greg Wooledge <g...@wooledge.org> wrote: > 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.
This thread has taken a life of its own and I have learned quite a bit from our back and forth. This is not how I intuitively thought it worked. I thought you had to actively ask the OS to update itself ... Now I am interested in learning all there is to be learned from this whole time keeping methodology and how it relates to systemd and the boot process. Is there a way to start the Linux kernel of a Debian Live running instance enabling you to log the whole process (in a more in depth way than dmesg) and then go "follow tcp" for each listed process in dmesg as you do with wireshark? lbrtchx
