[SOLVED} Wake on RTC only at 00:00 UTC

FallenArches · 2023-03-07 00:50:03

I have been trying to configure a desktop (not laptop) machine to wake from suspend or hibernate at a particular time but it will only wake on the power switch on the case or at 7pm local time which happens to be 00:00 UTC. Is that a clue?

I followed Power management (sleep hooks) and set up my autowake.service like so:

[root@archie ~]# systemctl cat autowake.service 
# /etc/systemd/system/autowake.service
[Unit]
Description=Test from https://wiki.archlinux.org/title/Power_management#Combined_suspend/resume_service_file
Before=sleep.target
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/root/bin/setwakeup suspend
ExecStop=-/root/bin/setwakeup resume

[Install]
WantedBy=sleep.target

In the setwakeup script I use

rtcwake -v -m no -s 120

(or many variations of the above) to set a wake up time if called with the suspend argument but it does not seem to matter what value I use for the -s or -t switch.
My setwakeup script currently looks like:

#! /bin/bash
# vim: ft=sh

echo "--$1--"
rtcwake -v -m show

My most resent test gave me this

[root@archie ~]# journalctl -u autowake.service
---- SNIP ----
Mar 06 18:46:40 archie systemd[1]: Starting Test from https://wiki.archlinux.org/title/Power_management#Combined_suspend/resume_service_file...
Mar 06 18:46:40 archie setwakeup[2162]: --suspend--
Mar 06 18:46:40 archie setwakeup[2163]: Using UTC time.
Mar 06 18:46:40 archie setwakeup[2163]:         delta   = 0
Mar 06 18:46:40 archie setwakeup[2163]:         tzone   = 0
Mar 06 18:46:40 archie setwakeup[2163]:         tzname  = UTC
Mar 06 18:46:40 archie setwakeup[2163]:         systime = 1678146400, (UTC) Mon Mar  6 23:46:40 2023
Mar 06 18:46:40 archie setwakeup[2163]:         rtctime = 1678146400, (UTC) Mon Mar  6 23:46:40 2023
Mar 06 18:46:40 archie setwakeup[2163]: alarm 0, sys_time 1678146400, rtc_time 1678146400, seconds 0
Mar 06 18:46:40 archie setwakeup[2163]: suspend mode: show; printing alarm info
Mar 06 18:46:40 archie setwakeup[2163]: alarm: on  Mon Mar  6 21:04:33 2023
Mar 06 18:46:40 archie systemd[1]: Finished Test from https://wiki.archlinux.org/title/Power_management#Combined_suspend/resume_service_file.
Mar 06 19:00:25 archie setwakeup[2331]: --resume--
Mar 06 19:00:25 archie setwakeup[2332]: Using UTC time.
Mar 06 19:00:25 archie setwakeup[2332]:         delta   = 0
Mar 06 19:00:25 archie setwakeup[2332]:         tzone   = 0
Mar 06 19:00:25 archie setwakeup[2332]:         tzname  = UTC
Mar 06 19:00:25 archie setwakeup[2332]:         systime = 1678147225, (UTC) Tue Mar  7 00:00:25 2023
Mar 06 19:00:25 archie setwakeup[2332]:         rtctime = 1678147225, (UTC) Tue Mar  7 00:00:25 2023
Mar 06 19:00:25 archie setwakeup[2332]: alarm 0, sys_time 1678147225, rtc_time 1678147225, seconds 0
Mar 06 19:00:25 archie setwakeup[2332]: suspend mode: show; printing alarm info
Mar 06 19:00:25 archie setwakeup[2332]: alarm: on  Mon Mar  6 21:04:33 2023
Mar 06 19:00:25 archie systemd[1]: Stopping Test from https://wiki.archlinux.org/title/Power_management#Combined_suspend/resume_service_file...
Mar 06 19:00:25 archie systemd[1]: autowake.service: Deactivated successfully.
Mar 06 19:00:25 archie systemd[1]: Stopped Test from https://wiki.archlinux.org/title/Power_management#Combined_suspend/resume_service_file.
[root@archie ~]#

I am baffled. How do I determine what woke up the PC? Any ideas?

If it helps:

[root@archie ~]# cat /proc/cmdline 
BOOT_IMAGE=/vmlinuz-linux root=UUID=ea5fc89c-6665-4a78-afe0-bc32d571a531 rw loglevel=3 quiet rtc_cmos.use_acpi_alarm=1 initcall_debug resume=UUID=e651e9eb-a560-4725-b8ae-b47df9c5039d
[root@archie ~]#

Last edited by FallenArches (2023-03-12 06:59:32)

seth · 2023-03-07 08:07:47

Mar 06 18:46:40 archie setwakeup[2163]: systime = 1678146400, (UTC) Mon Mar 6 23:46:40 2023
Mar 06 18:46:40 archie setwakeup[2163]: rtctime = 1678146400, (UTC) Mon Mar 6 23:46:40 2023
Mar 06 18:46:40 archie setwakeup[2163]: alarm 0, sys_time 1678146400, rtc_time 1678146400, seconds 0
Mar 06 18:46:40 archie setwakeup[2163]: suspend mode: show; printing alarm info
Mar 06 18:46:40 archie setwakeup[2163]: alarm: on Mon Mar 6 21:04:33 2023

The wakup time is ~2:40h in the past

Sanity checks:
1. does it work as expected if you

sudo rtcwake -v -u -m mem -s 60 # this will sleep immediately, add "-n" for just the output

2.

rtc_cmos.use_acpi_alarm=1

Mitigational effort? Why is that there?
3. If there's a parallel windows, see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

Last edited by seth (2023-03-07 08:08:07)

FallenArches · 2023-03-07 10:00:03

seth wrote:

Mar 06 18:46:40 archie setwakeup[2163]: systime = 1678146400, (UTC) Mon Mar 6 23:46:40 2023
Mar 06 18:46:40 archie setwakeup[2163]: rtctime = 1678146400, (UTC) Mon Mar 6 23:46:40 2023
Mar 06 18:46:40 archie setwakeup[2163]: alarm 0, sys_time 1678146400, rtc_time 1678146400, seconds 0
Mar 06 18:46:40 archie setwakeup[2163]: suspend mode: show; printing alarm info
Mar 06 18:46:40 archie setwakeup[2163]: alarm: on Mon Mar 6 21:04:33 2023
The wakup time is ~2:40h in the past

Good catch! Feeling kind of embarrassed.

seth wrote:

Sanity checks:
1. does it work as expected if you
sudo rtcwake -v -u -m mem -s 60 # this will sleep immediately, add "-n" for just the output

Not quite as I expect. Regardless of the -[alu] switch or -m [mem|disk] the machine will suspend to disk or memory but it will not awaken in 60 seconds. It does revive with a press of the power button on the case. With -m on the command line does pause for the expected time.

seth wrote:

2.
rtc_cmos.use_acpi_alarm=1
Mitigational effort? Why is that there?

Yes. Forget why now.

seth wrote:

3. If there's a parallel windows, see the 3rd link below. Mandatory.
Disable it (it's NOT the BIOS setting!) and reboot windows and linux twice for voodo reasons.

There is no other OS on the box.

I'll be picking up a new CMOS battery today even though I have not seen any evidence that the RTC loses/gains any time while the box is suspended|hibernated|shutdown.

Back after 19:00 EST

FallenArches · 2023-03-08 16:09:45

Sorry for being late but we had a fire on my floor of the apartment building so I lost most of yesterday for working on this issue.

On the plus side the new battery on the mother board seems to have done the trick! I will do more testing to confirm and then mark this SOLVED if all goes well.

FallenArches · 2023-03-08 17:08:24

Something is puzzling me.

I had seen a number of incidents where the PC resumed from S3 or S4 at 7pm local time regardless of what time I wanted the machine to resume. As noted above, 7pm local time is 00:00 UTC which I thought might be a clue to the issue. How could a dead CMOS battery cause this? Or even just a very run down battery? Something is going on that I don't understand and that bugs me.

Thanks for any explanations, ideas, or wild *ss guesses.

seth · 2023-03-08 20:00:50

I assume that the 0:00 stems from the stale wakeup entry and the entry is stale because it's placed in the past.
How a drowned CMOS battery could cause the latter is frankly beyond me (if we would assume that the RTC doesn't work b/c of that, how do we arrive at the wakeup aligning w/ 0:00 UTC on the wall clock)

Arch Linux

#1 2023-03-07 00:50:03

[SOLVED} Wake on RTC only at 00:00 UTC

#2 2023-03-07 08:07:47

Re: [SOLVED} Wake on RTC only at 00:00 UTC

#3 2023-03-07 10:00:03

Re: [SOLVED} Wake on RTC only at 00:00 UTC

#4 2023-03-08 16:09:45

Re: [SOLVED} Wake on RTC only at 00:00 UTC

#5 2023-03-08 17:08:24

Re: [SOLVED} Wake on RTC only at 00:00 UTC

#6 2023-03-08 20:00:50

Re: [SOLVED} Wake on RTC only at 00:00 UTC

Board footer