Bug: OBS WebSocket stays running in zombie process after OBS crash and does not terminate

[reedog117]

Operating System Info

Other

Other OS

Windows Server 2019

OBS Studio Version

28.1.x

OBS Studio Version (Other)

No response

obs-websocket Version

5.0.1

OBS Studio Log URL

<Removed by tt2468>

OBS Studio Crash Log URL

No response

Expected Behavior

Upon OBS crash, the websocket port should be released and the websocket server terminated. This way, when OBS is restarted, websocket can listen on its configured port.

Current Behavior

A rogue websocket server process is still running but unresponsive. It is taking up the port and preventing connections inbound to websocket.

Steps to Reproduce

1. Run OBS with Websocket enabled
2. Induce an unexpected freeze or crash of OBS requiring killing it via Task Manager
3. Restart OBS
   ...

Anything else we should know?

No response

[reedog117]

To add to this, I am able to see the zombie process listening here similar to this StackOverflow issue, but there is no way to actually kill the process without a full system reboot.

https://superuser.com/questions/215351/how-do-i-kill-a-process-that-is-dead-but-listening

[tt2468]

I've seen this issue only once before. Unfortunately, I've not been able to reproduce or diagnose it. My only thought is that it could be related to network drivers or something specific to the machine/VM itself. I have previously attempted to bump our ASIO version in hopes that it could provide some better behavior, but unfortunately due to a Mac crash bug, we're unable to upgrade.

[reedog117]

I think it may be staying open since when OBS dies it may not be taking all of its obs-browser-page.exe processes with it. As a result there may be a lingering "parent" process that needs to be terminated for port 4455 to finally be released.

Windows Command Prompt commands to determine parent processes

netstat -ano | find "4455"
REM get process id from last column
wmic process get processid,parentprocessid | findstr /i <process id from last command>
REM now use the parent process id number in the second column
wmic process where (ParentProcessId=<parent pid>) get Caption,ProcessId

[MrMase]

I wonder if this is the same issue that has been causing issues with my OBS for the past couple months, it led to me writing the following batch script for when it occurs.

ipconfig /release
ipconfig /flushdns
ipconfig /renew
netsh int ip reset
netsh winsocket reset
shutdown -r -f -t 50

[Gambloide]

In #1175 I mentioned only being able to connect to OBS websocket seemingly randomly by combinations of enabling/disabling IPv6 and passing/not passing the --websocket_ipv4_only flag followed by a reboot when I open OBS for the second or more time in a day.

I have had the issue again twice today and the first time enabling IPv6 and removing the --websocket_ipv4_only flag again made it work again, until I closed and started OBS again, which made it unresponsive again.

It only showed the by now all too familiar error:

00:09:59.946: [obs-websocket] [WebSocketServer::Start] Locked to IPv4 bindings
00:09:59.946: [obs-websocket] [WebSocketServer::Start] Listen failed: Only one usage of each socket address (protocol/network address/port) is normally permitted.

The second time I checked netstat and sure enough, even though the logs said it failed to listen, I had multiple bindings on 0.0.0.0:4455 and 127.0.0.1:4455 in either status LISTENING or CLOSE_WAIT even though the associated PIDs could not be found in tasklist. Even 30 minutes later, these bindings would not disappear, which would explain why OBS-Websocket failed to bind the port and listen.

There has been no indication of any crashes from the UI or in the logs that I can see. I have closed OBS via the Exit button in these instances.

But going in and changing the port from 4455 to 4456 and stopping/starting the server again made it able to bind again.
So I guess messing the IPv6 vs IPv4 just made it so I could circumvent the issue by binding the port to another protocol.

This is on Windows 10 with OBS 30.0.0 64bit using the version of OBS Websocket shipped with OBS. I also did multiple file integrity checks in OBS and everything is reported fine.

---

I haven't had this issue with OBS Websocket 4, only with 5. Maybe its related to closing OBS while something goes down the socket(s)? I was able to use the inbuilt heartbeat event with OBS Websocket 4, but since that's not a thing anymore with 5 and the stats also do not report kbps anymore I had to resort to heartbeating more aggressively to get stats, besides all the other traffic going over the sockets for controlling scenes, sources and overlays.

[rondhi]

I've been experiencing this as well after updating to OBS 30.0.0. Sometimes OBS crashes after clicking exit. The websocket port isn't being properly released. I have to restart my PC to fix it. Not sure how to read a crash report, but I imagine one of the OBS plugins are causing a crash.

Using Streamer.bot and OBS-websocket is essential to me. For now, I've reverted to OBS 29.1.2, as the port is properly being released, even if there's a crash. If you need more information, I'm happy to provide.

I'll have to install the plugins one by one until I can recreate the crash behavior.

[nuttylmao]

I've been experiencing this as well after updating to OBS 30.0.0. Sometimes OBS crashes after clicking exit. The websocket port isn't being properly released. I have to restart my PC to fix it. Not sure how to read a crash report, but I imagine one of the OBS plugins are causing a crash.

Using Streamer.bot and OBS-websocket is essential to me. For now, I've reverted to OBS 29.1.2, as the port is properly being released, even if there's a crash. If you need more information, I'm happy to provide.

I'll have to install the plugins one by one until I can recreate the crash behavior.

I've been in the same boat for months. Not sure if it's related to OBS 30 but yes, this seems to happen even when OBS shuts down properly without crashing.

[MichiShyGuy]

For me this issue also started to occur since I upgraded to 30. Even when normally shutting down OBS, though OBS thinks it crashed anyways, because it asks me next time if I want to use Safe Mode.
It also wasn't resolved with the recent patches.

[devolore]

I have also been experiencing this issue since OBS 30, including on 30.0.2, exactly as above: close OBS normally -> reopen OBS -> receive prompt to open in Safe Mode -> Click no -> Websockets are not working.

[platinumazure]

Exactly like devolore, I've been experiencing this issue since OBS 30 with the exact same repro steps.

However, I discovered a potential workaround (at least it seems to work for me on a couple of attempts):

Disregard the below. My real issue is that Mix It Up (another websocket client) does not handle the websocket server termination properly, in such a way that OBS Studio ends up crashing. It would still be ideal if obs-websocket could release the server port when OBS Studio crashes.

1. In OBS Studio, go to Websocket Server Settings and disable the websocket server.
2. Close OBS Studio and reboot.
3. Open OBS Studio. Go to Websocket Server Settings and enable the websocket server.
4. Close OBS Studio.
5. Reopen OBS Studio.

Result: No Safe Mode prompt, and my websocket client (in this case Stream Deck plugins) are able to connect to obs-websocket again. This persists even afer closing and reopening OBS Studio a few more times.

On the other hand, when I leave the websocket server ON and then reboot my computer, then it goes back to the same behavior reported by devolore.

Hope this helps (either as a workaround or to help troubleshoot the issue)!

[rondhi]

I believe my issue was caused by DroidCam OBS. if you have the DroidCam OBS plugin installed, please make sure that you've installed the latest DroidCam update, which fixed an issue that broke obs-websocket

[platinumazure]

Thanks @rondhi, updating to latest DroidCam OBS did fix my issue.

Mix It Up still seems to crash OBS Studio if it is open when OBS Studio is closed. But it does so without the port being tied up.

So from my perspective, this is no longer a bug that impacts me, but if there's any way to enhance websocket to forcibly close ports when it needs to, that could still be useful.

[tt2468]

The issue with Droidcam was that it spawned an ADB process with a special mode which would copy the socket file descriptors running in OBS to that ADB process, and the ADB process would stay running when OBS would shut down. That's simply not something we can control.

Unless @reedog117 is also using droidcam (I don't think he is), then this would have been a hijack of this issue, so I'm going to leave it open for the time being.

Regarding the original report, @reedog117 I had to originally remove your OBS log since it contained private information in the form of your media source URLs. If you still encounter this issue, please re-post a new log demonstrating it.

[MrMase]

Agree this issue is not Droidcam specific as when previously commenting myself I'm not using either of these. In my case OBS websockets were being accessed by BarRaider addons in Elgato's StreamDeck software or KruizControl by Kruiser8.

…

________________________________ From: tt2468 ***@***.***> Sent: Sunday, December 31, 2023 9:37:28 PM To: obsproject/obs-websocket ***@***.***> Cc: MrMase ***@***.***>; Comment ***@***.***> Subject: Re: [obsproject/obs-websocket] Bug: OBS WebSocket stays running in zombie process after OBS crash and does not terminate (Issue #1085) The issue with Droidcam was that it spawned an ADB process with a special mode which would copy the socket file descriptors running in OBS to that ADB process, and the ADB process would stay running when OBS would shut down. That's simply not something we can control. Unless @reedog117<https://github.com/reedog117> is also using droidcam (I don't think he is), then this would have been a hijack of this issue, so I'm going to leave it open for the time being. Regarding the original report, @reedog117<https://github.com/reedog117> I had to originally remove your OBS log since it contained private information in the form of your media source URLs. If you still encounter this issue, please re-post a new log demonstrating it. — Reply to this email directly, view it on GitHub<#1085 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACFG2CKSM7OWB7MTT46CEFTYMHLJRAVCNFSM6AAAAAATCKVXG6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZTGA2DCMZSG4>. You are receiving this because you commented.Message ID: ***@***.***>