Systemd timers and service

Ok ? Have you seen the error output I posted ? It doesn’t work on my system :man_shrugging:
So how can I debug this ?

To be clear: if I remove the “WakeSystem=” line I can suspend / hibernate whatever with power buttons and CLI just fine (even as non-root).
If I put that line back I get :

kernel: PM: Some devices failed to suspend, or early wake event detected
systemd-sleep[14060]: Failed to put system to sleep. System resumed again: Device or resource busy

It seems to be a general error message because Google gives me all kinds of results not involving timers, so hard to search for it :expressionless:
Learning as I go here…

It is not about suspend and resume, but about the ability of your BIOS to wake up at specific time. Try testing using rtcwake. Something like (to resume after 60 seconds)

rtcwake -m mem -s 60
1 Like

Funny, I was just reading up on it in man page :grin:
Yeah something ain’t right here… I get :

rtcwake: wakeup from "mem" using /dev/rtc0 at Fri Jun  2 10:13:26 2023
rtcwake: write error

I also noticed it maybe has ‘wrong’ permissions ?

lrwxrwxrwx root root  4 B Thu Jun  1 23:29:05 2023  rtc ⇒ rtc0
crw-rw---- root audio 0 B Thu Jun  1 23:29:05 2023  rtc0

Says “audio” group. I did some experimenting with real-time audio stuff a while ago, could that be conflicting ?


Read back my post #15 above. Your answer in post #16 apparently now seems to be that you can resume pushing the Power button. But that is NOT what we are talking about here. We are talking about waking on an hard-/firmware internal timer of the system (the iron system, not the operating system).

So it seems that you did not even test that or tried to find info on it in the systems docs or the BIOS.

To me the ability to do the wake from internal timer is the crucial thing to have before trying anything else.

I hope you now see how important the if the system supports this. is.

1 Like

This message is printed when closing /sys/power/sleep after attempting to suspend. Which implies that suspend failed, and I bet that if you looked in kernel log you would have seen the same messages as before.

So, your BIOS does not cooperate well with attempt to schedule wakeup, at least using “standard” interface. There is nothing that can be done from Linux side. Try asking on hardware forums for your system/motherboard whether it is expected to work at all. Try whether it works from within Windows.

1 Like

Ok yes I see it now, I’ve got some research to do. Already noticed some APM stuff was disabled in BIOS…

Thanks @arvidjaar, you’ve been most helpful and to-the-point :+1:
Thanks @karlmistelberger for the testing and patience.

Hello this is Gulshan Negi
Not much idea about it, however you can try this code as radio.service file.

Description=Stream radio through nvlc

ExecStart=/usr/bin/systemd-run --scope --user /home/bart/bin/scripts/


Hope it will work.

1 Like

Hey thanks for replying.

Yeah I got it working for some time now. The only thing still bugging me is how to make sure when - after waking up - the network connection is “live” so the stream can start.

I’ve been playing around with “” and “” in my trigger.service but it’s not always sufficient. Added a “ExecStartPre=sleep…” in the radio.service as a workaround.

Anyway, works good enough for now :slightly_smiling_face:

As you are using Tumbleweed you most likely have NetworkManager, so I’d say the most simple way is to add to your service (not timer) something like

ExecStartPre=/usr/bin/nm-online --quiet

which will wait until NetworkManager reaches ONLINE state.

1 Like

Is this something that may help you?

1 Like

No, that won’t help. It is only relevant for startup and shutdown. Besides, if you actually read the post you probably answer (without indicating it by doing Reply), you would have seen that OP already used without success.

Yes, I had found and read that info at Running Services After the Network Is Up
Interesting read for sure :+1:

Gah, so simple :laughing:

You are correct, this solves the last issue :+1:

“Software that is written under the assumption that network connectivity is available continuously and never changes is hence not up-to-date with reality. Well-written software should be able to handle dynamic configuration changes. It should react to changing network configuration and make the best of it. If it cannot reach a server it must retry. If network configuration connectivity is lost it must not fail catastrophically. Reacting to local network configuration changes in daemon code is not particularly hard. In fact many well-known network-facing services running on Linux have been doing this for decades. A service written like this is robust, can be started at any time, and will always do the best of the circumstances it is running in.”

As I suspend my machines to RAM enabling target NetworkManager-wait-online doesn’t work reasonably. Therefore I disabled it:

3400g:~ # systemctl is-enabled NetworkManager-wait-online.service
3400g:~ # 

Some services needing the network:

 3400g:~ # systemctl cat fetchmail.service 
# /usr/lib/systemd/system/fetchmail.service
Description=A remote-mail retrieval utility



# /etc/systemd/system/fetchmail.service.d/override.conf
3400g:~ # 
3400g:~ # systemctl cat dup.service 
# /etc/systemd/system/dup.service
Description=Dist Upgrade

ExecStart=/usr/bin/zypper --non-interactive dist-upgrade
3400g:~ #