[BUG] swag-ondemand: Ignores websockets

[chripede]

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

1. Start linuxserver/firefox with swag_ondemand
2. Use it
3. 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

[quietsy]

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]

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]

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. /websockets for selkies, /embywebsocket for 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]

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]

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.