Created attachment 700419 [details] emerge --info Package info: sys-apps/systemd-247.2-r4:0/2::gentoo USE="acl gcrypt hwdb kmod lz4 pam pcre (policykit) resolvconf seccomp (split-usr) sysv-utils zstd -apparmor -audit -build -cgroup-hybrid -cryptsetup -curl -dns-over-tls -elfutils -gnuefi -homed -http -idn -importd -lzma -nat -pkcs11 -pwquality -qrcode -repart (-selinux) -static-libs -test -vanilla -xkb" ABI_X86="32 (64) (-x32)" Kernel: Linux HAL-9001 5.10.27-gentoo #8 SMP PREEMPT Tue Apr 13 01:16:09 -04 2021 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux Current behaviour: Systemd keeps changing the Localtime after every system boot. > Local time: jue 2021-04-15 07:27:02 -04 > Universal time: jue 2021-04-15 11:27:02 UTC > RTC time: jue 2021-04-15 11:27:02 > Time zone: America/Santiago (-04, -0400) > System clock synchronized: no > NTP service: inactive > RTC in local TZ: yes Steps to reproduce the problem: > # timedatectl set-local-rtc 1 > # timedatectl set-time "2021-04-15 11:24" > reboot After step 2 # hwclock, $ date and the BIOS show the correct time. Expected behaviour: Systemd should follow the RTC in local TZ config (# timedatectl set-local-rtc 1) and adjust the UTC from the RTC accordly. > Local time: jue 2021-04-15 11:24:55 -04 > Universal time: jue 2021-04-15 15:24:55 UTC > RTC time: jue 2021-04-15 11:24:56 > Time zone: America/Santiago (-04, -0400) > System clock synchronized: no > NTP service: inactive > RTC in local TZ: yes Additional info: # ls -l /etc/localtime lrwxrwxrwx 1 root root 38 sep 8 2020 /etc/localtime -> ../usr/share/zoneinfo/America/Santiago # sha512sum ../usr/share/zoneinfo/America/Santiago 4ccf1f22ed9e780694ffa97dcaecbd2cb7239dde0c2e70fd4931a355086f6398d83609f8ba3b682719dcb08792552dec01a4a4fa467a43809c3c4dd23db09bb9 ../usr/share/zoneinfo/America/Santiago Regards.
It works fine for me. Do you see a message like this in "journalctl -b"? > Apr 17 13:24:14 naomi systemd[1]: RTC configured in localtime, applying delta of -240 minutes to system time.
You may need to run "hwclock --systohc" after setting the system clock. Otherwise, the hardware realtime clock will not be updated. Also note the big warning that timedatectl outputs: > Warning: The system is configured to read the RTC time in the local time zone. > This mode cannot be fully supported. It will create various problems > with time zone changes and daylight saving time adjustments. The RTC > time is never updated, it relies on external facilities to maintain it. > If at all possible, use RTC in UTC by calling > 'timedatectl set-local-rtc 0'.
The RTC clock is well setted. There aren't any problems with the RTC, after adjusting the time with # timedatectl set-time, date, hwclock and the BIOS time are all fine. Unfortunately # hwclock --systohc makes not difference. Do you see a message like this in "journalctl -b"? > Apr 17 13:24:14 naomi systemd[1]: RTC configured in localtime, applying delta of -240 minutes to system time. Yes, exactly that: > abr 17 13:51:47 HAL-9001 systemd[1]: RTC configured in localtime, applying delta of -240 minutes to system time.
I was testing with systemd-248; it might be worth trying that version.
(In reply to Mike Gilbert from comment #4) > I was testing with systemd-248; it might be worth trying that version. Unfortunately I can't test that for at least a few weeks. Anything else I could check out in the meantime? Thanks for the time (:P)
The only other thing I can think of is that something is messing with the clock before or after systemd starts. Maybe something in an initramfs?
AFAIK nothing special on boot, never use initramfs on the system. > # grep 'CONFIG_INITRAMFS_SOURCE' /usr/src/linux/.config CONFIG_INITRAMFS_SOURCE="" > # grep 'initrd' /boot/grub/grub.cfg > #
Do you have any NTP client or something like that?
(In reply to Michał Górny from comment #8) > Do you have any NTP client or something like that? No NTP here :S > # qlist -I | grep ntp > # Doesn't this log entry say that systemd is doing something?: > abr 17 13:51:47 HAL-9001 systemd[1]: RTC configured in localtime, applying delta of -240 minutes to system time. Shouldn't the delta be 0? (don't know if for systemd is relative to UTC or RTC) Correct time (13:25) # date > dom 18 abr 2021 09:25:06 -04 # hwclock > 2021-04-18 13:25:09.046408-04:00 # hwclock --localtime > 2021-04-18 13:25:12.640073-04:00 # hwclock --utc > 2021-04-18 09:25:16.593206-04:00 # cat /etc/adjtime > 0.000000 1618682672 0.000000 > 1618682672 > LOCAL
(In reply to Eduardo Bray from comment #9) > Shouldn't the delta be 0? (don't know if for systemd is relative to UTC or > RTC) When the kernel starts, it always assumes the hardware RTC is stored in UTC. The kernel then starts systemd as PID 1. systemd looks at /etc/adjtime, and if the third line is "LOCAL" it adjusts the system clock by adding or subtracting time based on the UTC offset specified in the timezone data (/etc/localtime). That's what the "RTC configured in localtime, applying delta" message is about. The delta would only be 0 if your hardware RTC is configured for UTC.
(In reply to Mike Gilbert from comment #10) Thanks for the info! Since I can't provide enough information to reproduce the issue, the bug should be closed and open another one for version 248 when I can perform the update? I just added "date -s '4 hours'" to a script to correct it on every startup
