On Mon, Dec 25, 2023 at 03:35:04PM +0000, Albretch Mueller wrote: > 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.
Be sure to read the other responses to that message. There's a weird timing issue caused by the fact that running "timedatectl" triggers a service process to run, unless one is already running. This service process only stays running for 30 seconds, and it only reads the /etc/localtime symlink when it starts up. So, if you've already got one running, it won't pick up a changed /etc/localtime. But if you wait until the current one dies, then the *next* one will. I have no idea why this subsystem was designed to work this way. It seems awkward to me, but I'll give them the benefit of the doubt for now -- there's probably *some* reason to do it this way, even if it's not immediately clear to me. > 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? If you want to see what a process is doing, there's strace. It can even be told to follow all the children of a process (strace -f).
