Repository navigation
WoL support #84
Description
Activity
I am using a small python script as a service running in the host to listen wol packages. Once I get a wol packet I just run a docker command to start the container. May share the script but i need to polish it before share it
Reacted by Josh Sunnex and TheQuickestFoxReacted by Josh SunnexThis is a great use case — having the container idle and wake on demand would be a huge power saver for headless gaming rigs.
I built a tool called idle-less that tackles a similar problem at the Docker reverse proxy level. It sits in front of your services and automatically sends Wake-on-LAN packets when an incoming request hits a sleeping backend, then proxies the traffic once the target is up. When things go idle, the backend can suspend again.
It won't solve the in-container supervisor approach you described, but if your Steam Headless container runs on a separate machine (or you want to wake the entire host on demand), idle-less can handle the WoL trigger transparently through HTTP/HTTPS requests — no host-mode networking required.
Might be worth a look if the external wake approach fits your setup: https://github.com/tvup/idle-less
Is your feature request related to a problem?
Running a Steam Headless container can take up a bit of RAM. I would like to reduce the container use when it is not doing anything.
What is your feature request?
I believe we could check for running processes on the desktop. If nothing is running (no Steam games or Moonlight connections), then we can safely assume that the container is "idle". When it is idle for a set period of time, perhaps an hour, we could stop all processes supervisord is running and put the container to sleep with the exception of a small WoL listener service.
When this Listener service is triggered by either Moonlight or Steam Link, it can "wake up" the services again and restart the desktop.
We could either do this completely internally within the container, or we could pass the host Docker socket to the container and have it issue restart commands to itself.
Are there any workarounds?
We can sort of do this already if the container is run in "host" mode and we use an external WoL listener service to trigger commands. But this will not work if we are using any other Docker network type.
Additional Context
No response