On Thu, Dec 21, 2023 at 10:36:06PM +0700, Max Nikulin wrote: > 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.
Hmm. OK, logs do seem to support that this could be the case. unicorn:~$ sudo systemctl status systemd-timedated [...] Dec 21 07:18:14 unicorn systemd[1]: Starting systemd-timedated.service - Time &> Dec 21 07:18:14 unicorn systemd[1]: Started systemd-timedated.service - Time & > Dec 21 07:18:44 unicorn systemd[1]: systemd-timedated.service: Deactivated succ> Dec 21 07:25:47 unicorn systemd[1]: Starting systemd-timedated.service - Time &> Dec 21 07:25:47 unicorn systemd[1]: Started systemd-timedated.service - Time & > Dec 21 07:26:39 unicorn systemd[1]: systemd-timedated.service: Deactivated succ> Dec 21 07:26:59 unicorn systemd[1]: Starting systemd-timedated.service - Time &> Dec 21 07:26:59 unicorn systemd[1]: Started systemd-timedated.service - Time & > Dec 21 07:27:29 unicorn systemd[1]: systemd-timedated.service: Deactivated succ> > 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". "Expected" by... well, not by *me*, that's for sure. Maybe expected by systemd developers? Now I'm really curious what that command does. Let's find out. unicorn:~$ sudo timedatectl set-timezone America/Chicago unicorn:~$ ls -ld /etc/timezone /etc/localtime lrwxrwxrwx 1 root root 37 Dec 21 12:18 /etc/localtime -> ../usr/share/zoneinfo/America/Chicago -rw-r--r-- 1 root root 17 Dec 9 07:33 /etc/timezone Looks like it does NOT know about Debian's legacy /etc/timezone file, and does not update it. I therefore cannot recommend that anyone on a Debian system use this command to change their time zone, unless they follow it up by manually editing /etc/timezone.
