Summary: | sys-apps/systemd-247.2-r4 Local time keeps changing on every boot | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Eduardo Bray <ebray187> |
Component: | Current packages | Assignee: | Gentoo systemd Team <systemd> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | mgorny |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info |
Description
Eduardo Bray
2021-04-17 17:02:06 UTC
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 |