Repository navigation
[BUG] swag-ondemand: Ignores websockets #1090
Description
Is there an existing issue for this?
- I have searched the existing issues
Name of mod
When using something like linuxserver/firefox with swag_ondemand, swag will kill the container while it is being used, because all traffic is done via an open websocket. I guess that is because nothing is logged as the connection is long living.
Name of base container
swag
Current Behavior
Kills active container
Expected Behavior
The container should not be killed while in use
Steps To Reproduce
- Start linuxserver/firefox with swag_ondemand
- Use it
- Wait for the kill timeout
Environment
- OS:
- How docker service was installed:CPU architecture
x86-64
Docker creation
.Container logs
2025-11-29 22:07:27 - Thread-1 - INFO - Started firefox
2025-11-29 22:23:43 - Thread-1 - INFO - Stopped firefox after 600s of inactivity
2025-11-29 22:23:48 - Thread-1 - INFO - Started firefox
Activity
quietsy commentedon Dec 9, 2025
If nothing is logged in access.log, you'll have to manually invoke it with a hard refresh (ctrl+f5) every X minutes. It'll be more convenient for you to increase the stop threshold to 1 hour or more.
LinuxServer-CI commentedon Jan 9, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
aptalca commentedon Feb 11, 2026
I also got bit by this. I have ondemand set to shut down chrome in 10 minutes. I was making a purchase, got to the payment screen, entered credit card info and hit submit. . . and the container shut down 🤦 worst timing ever lol.
So I looked into it. I noticed that whenever the websocket connection is terminated (browser window closed, or timed out, etc.), nginx logs to the access log, which is something the mod can use to determine the end of the session.
One thing the mod can do is, perhaps accept a new label for the websocket endpoint (ie.
/websocketsfor selkies,/embywebsocketfor Emby, etc.) and watch for the log entry that indicates the end of the websocket session before determining idleness.The log entry for chrome looks like this:
192.168.XX.XX - - [06/Jan/2026:14:31:38 -0500] "GET https://chrome.mydomain/websockets HTTP/1.1" 101 14898391 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
For Emby it looks like this:
192.168.XX.XX - - [06/Jan/2026:14:33:35 -0500] "GET https://emby.mydomain/embywebsocket?api_key=XXXXXXXXXXXXX&deviceId=XXXXX-XXXX-XXXXX-XXXXX HTTP/1.1" 101 0 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
I tested a bunch of times and very reliably that log entry happens when I close the browser window or navigate away.
aptalca commentedon Feb 11, 2026
I just tested with code-server as well. It's another app where once opened and loaded, all further communication occurs through websockets so nothing is logged while the session is active. But once closed or navigated away, it logs 2 101 responses (I guess it maintains 2 websocket connections).
And no matter what I tried, all websocket based connections always terminate with 101 response codes in the nginx logs so perhaps we don't even need to define the websocket endpoint but simply set a boolean for websockets and if true, the mod can look for a 101 response code in the logs following a successful 200 code to determine idleness, and start the shut down timer after the 101 log entry.
LinuxServer-CI commentedon Mar 14, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
LinuxServer-CI commentedon Jun 13, 2026
This issue is locked due to inactivity
quietsy commentedon Aug 26, 2026
Should be fixed with the label
- swag_ondemand_websocket=1in recent versions.