[Solved] Clock is temporarily off after every wake-from-sleep/boot

[m4c-attack]

It's the most random thing.,,

Let's say I shut down my system or it goes to sleep @ 9:45pm

If I were to boot my system the following morning and log in, if I check the time, it will say 9:45pm.

It both is and isn't persistent:

• It is persistent in that it happens every time I boot
  It's not persistent in that it resolves within about 3-10 seconds after I've logged in

Some resulting issues:

• I use KDE and run a systemd service+timer that changes to a light/dark theme when the computer (re)boots and it is 'failing' on its first try due to the time being off.
  Syncthing has a systemd service as well... if I create/edit files on my tablet in the morning, and then it is set to auto-sync to my desktop when it boots, the metadata is applied retroactively and suggests the file was actually updated/edited the prior evening
  It's likely doing unforeseen damage to my journal logs and the occasional systemd service

Curious if anyone has any theories/solutions?

[bin]

Slow connecting to router/internet? No net = no NTP service.

[Aki]

Hello,

What is your computer ?

What is your Debian installed version ?

Let's say I shut down my system or it goes to sleep @ 9:45pm
[..]
If I were to boot my system the following morning and log in, if I check the time, it will say 9:45pm.
[..]
It's not persistent in that it resolves within about 3-10 seconds after I've logged in

Desktops and notebooks usually have an internal "hardware" real time clock (RTC) that is powered by an internal battery. This is your computer's reference real-time clock. It ticks even if the computer is off (as long as it is powered by its battery).

The operating system (Debian) initialises the so-called "system clock" (software clock maintained by the kernel, see [1]) from the RTC at boot time.

You can check system logs about RTC with the following command:

Code: Select all

sudo journalctl -b --grep rtc

The operating system can then update the system time (within certain limits) from another networked computer using "network time servers".

Perhaps, there something wrong with the RTC in your computer.

--
[1] https://manpages.debian.org/bookworm/nvram-wakeup/rtc.8.en.html

[m4c-attack]

Responses in bold

Slow connecting to router/internet? No net = no NTP service.
You might be onto something. There's also a few seconds delay before the ethernet kicks in I've found. I wonder if there's a logjam in systemd that is cascading down to all the dependencies?

Hello,

What is your computer ?
Optiplex 7060
What is your Debian installed version ?
lsb_release is never nuanced enough but 12.4 or whatever the latest version of Bookworm is.

Desktops and notebooks usually have an internal "hardware" real time clock (RTC) that is powered by an internal battery. This is your computer's reference real-time clock. It ticks even if the computer is off (as long as it is powered by its battery).
This was my initial theory as well. The part that made me unsure was that my Googles only saw instances where the clock stayed wrong after boot and had to be manually adjusted. The fact that it keeps righting itself after a few seconds makes me second guess that theory but it could definitely be the culprit

The operating system (Debian) initialises the so-called "system clock" (software clock maintained by the kernel, see [1]) from the RTC at boot time.

You can check system logs about RTC with the following command:

Code: Select all

sudo journalctl -b --grep rtc

The operating system can then update the system time (within certain limits) from another networked computer using "network time servers".
Appreciate the query, I will dig around tomorrow and report back!

[m4c-attack]

sudo journalctl -b --grep rtc

Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: RTC can wake from S4
Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: registered as rtc0
Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: setting system clock to 2023-09-14T20:31:04 UTC (1694723464)
Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: alarms up to one month, y3k, 242 bytes nvram
Jan 26 15:48:36 optiplex systemd[1]: RTC configured in localtime, applying delta of -300 minutes to system time.
Apr 14 21:37:20 optiplex systemd-timesyncd[690]: The system is configured to read the RTC time in the local time zone. This mode cannot be fully supported. All system time to RTC updates are disabled.
Apr 15 10:19:58 optiplex plasmashell[3235]: kf.xmlgui: Shortcut for action "mainToolBar" "Show Toolbar" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Apr 15 10:19:58 optiplex plasmashell[3235]: kf.xmlgui: Shortcut for action "" "Show SSH Manager" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Apr 15 10:19:58 optiplex plasmashell[3235]: kf.xmlgui: Shortcut for action "" "Show Quick Commands" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Apr 15 10:20:11 optiplex plasmashell[3235]: Skipped method "setDefaultShortcuts" : Pointers are not supported: QAction*
Apr 15 10:20:11 optiplex plasmashell[3235]: Skipped method "setDefaultShortcuts" : Pointers are not supported: QAction*

Nothing pops out there, but I did dig around beyond the last boot and might have found something:
sudo journalctl --grep rtc | tail

Apr 14 21:37:20 optiplex systemd-timesyncd[690]: The system is configured to read the RTC time in the local time zone. This mode cannot be fully supported. All system time to RTC updates are disabled.
Apr 15 10:19:58 optiplex plasmashell[3235]: kf.xmlgui: Shortcut for action "mainToolBar" "Show Toolbar" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Apr 15 10:19:58 optiplex plasmashell[3235]: kf.xmlgui: Shortcut for action "" "Show SSH Manager" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Apr 15 10:19:58 optiplex plasmashell[3235]: kf.xmlgui: Shortcut for action "" "Show Quick Commands" set with QAction::setShortcut()! Use KActionCollection::setDefaultShortcut(s) instead.
Apr 15 10:20:11 optiplex plasmashell[3235]: Skipped method "setDefaultShortcuts" : Pointers are not supported: QAction*
Apr 15 10:20:11 optiplex plasmashell[3235]: Skipped method "setDefaultShortcuts" : Pointers are not supported: QAction*
Apr 15 10:49:57 optiplex sudo[11027]: macattack : TTY=pts/1 ; PWD=/home/macattack/Downloads ; USER=root ; COMMAND=/usr/bin/journalctl -b --grep rtc
Apr 15 11:21:44 optiplex sudo[16946]: macattack : TTY=pts/1 ; PWD=/etc/network ; USER=root ; COMMAND=/usr/bin/journalctl --grep rtc
Apr 15 11:23:22 optiplex sudo[17103]: macattack : TTY=pts/1 ; PWD=/etc/network ; USER=root ; COMMAND=/usr/bin/journalctl --grep rtc
Apr 15 11:23:29 optiplex sudo[17128]: macattack : TTY=pts/1 ; PWD=/etc/network ; USER=root ; COMMAND=/usr/bin/journalctl --grep rtc

Lastly, I did take a look @ my network interface doc and it seems barebones but it's working. Not sure if I need to explicitly reference the eth connection or leave as is?
cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

Based on the comments and the threads below, I have three courses of actions I'm looking into:

• Digging around the BIOS to see if there are time-related settings that might be in the way

• Digging around the BIOS to see if there are 'optimized' default settings that might be in the way (as per https://forums.linuxmint.com/viewtopic.php?t=226427)

• Make edits to /etc/network/interfaces

Open to suggestions/feedback!

[bin]

I run an Optiplex 7040 - this is what i get

Code: Select all

sudo journalctl --grep rtc | tail
[sudo] password for robin:         
Apr 15 06:19:52 mopsy kernel: rtc_cmos 00:06: RTC can wake from S4
Apr 15 06:19:52 mopsy kernel: rtc_cmos 00:06: registered as rtc0
Apr 15 06:19:52 mopsy kernel: rtc_cmos 00:06: setting system clock to 2024-04-15T05:19:49 UTC (1713158389)
Apr 15 06:19:52 mopsy kernel: rtc_cmos 00:06: alarms up to one month, y3k, 242 bytes nvram
-- Boot 9f89b57a449d4f75adf4ccbececf5dba --
Apr 16 06:13:40 mopsy kernel: rtc_cmos 00:06: RTC can wake from S4
Apr 16 06:13:40 mopsy kernel: rtc_cmos 00:06: registered as rtc0
Apr 16 06:13:40 mopsy kernel: rtc_cmos 00:06: setting system clock to 2024-04-16T05:13:37 UTC (1713244417)
Apr 16 06:13:40 mopsy kernel: rtc_cmos 00:06: alarms up to one month, y3k, 242 bytes nvram

So it looks like that is indeed where something is a bit odd.

[Aki]

Hello,

Code: Select all

$ sudo journalctl -b --grep rtc
[quote]Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: RTC can wake from S4
Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: registered as rtc0
Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: setting system clock to 2023-09-14T20:31:04 UTC (1694723464)

Open to suggestions/feedback!

The real-time clock (RTC) appears to be about a year out of date in your computer:

Code: Select all

Jan 26 15:48:36 optiplex kernel: rtc_cmos 00:03: setting system clock to 2023-09-14T20:31:04 UTC (1694723464)

So you need to set it up. You can do this using operating system tools, but you can also do it easily using the computer's BIOS. After that, the motherboard battery must be able to keep it running, of course.

Code: Select all

Jan 26 15:48:36 optiplex systemd[1]: RTC configured in localtime, applying delta of -300 minutes to system time.
Apr 14 21:37:20 optiplex systemd-timesyncd[690]: The system is configured to read the RTC time in the local time zone. This mode cannot be fully supported. All system time to RTC updates are disabled.

In your Debian installation, the operating system is configured to interpret the RTC time as "localtime" instead of "UTC" (Greenwich Mean Time, or GMT). This can be caused by a dual-boot installation with other operating systems (such as Windows, see [1]).

See [2] for the source code of the message error in systemd.

Therefore, after setting the date and time in the RTC, you will need to configure Debian to interpret the RTC time as UTC, otherwise the RTC time will not be used by systemd to set the "system time clock" at boot time. You can do it changing the last line of /etc/adjtime from:

Code: Select all

LOCAL

to:

Code: Select all

UTC

or you can use the following command (as root) replacing the option "--date" value with the actual date-time (see [3]):

Code: Select all

hwclock --set --date='2024-04-16 23:00:00' --utc

Hope this helps.

note: Please, use code tags to include commands and/or their logs in the body of a message.

---
[1] The Debian Administrator's Handbook - 8.9.1. Timezone - Box "System clock, hardware clock"
[2] https://sources.debian.org/src/systemd/255.4-1/src/core/main.c/?hl=1581#L1581
[3] https://manpages.debian.org/bookworm/util-linux-extra/hwclock.8.en.html

[Aki]

@m4c-attack:
Did you sort it out ?

[m4c-attack]

@m4c-attack:
Did you sort it out ?

Yup. I followed your advice to the tee and then gave it a few days of booting to be sure. There was a brief moment where it looked like it reverted but I haven't been able to replicate it since.

Kinda blows my mind that you have knowledge of something as seemingly arbitrary as RTC btw lol. It feels like something that might be touched once per system lifetime lol