Ok ? Have you seen the error output I posted ? It doesn’t work on my system
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
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)
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.
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.
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 “Wants=network-online.target” and “After=network.target network-online.target” in my trigger.service but it’s not always sufficient. Added a “ExecStartPre=sleep…” in the radio.service as a workaround.
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 After=network-online.target without success.
“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.”
