neolink:latest runs away using up file descriptors when ffmpeg is connected to the rtsp port

[mooinglemur]

Describe the bug
If there is only one camera configured, neolink immediately goes into some sort of runaway state, using up all allowed file descriptors until reaching the limit, shortly after which the process crashes and the container restarts.

This behavior does not happen when there are more cameras (tested with 3 total cameras) configured. I have not tested it with 2.

To Reproduce
Steps to reproduce the behavior. Example:

1. Create this configuration file:

bind = "0.0.0.0"

[[cameras]]
name = "cam-streat"
username = "stream"
password = "<redacted>"
address = "192.168.31.19"
push_notifications = false

2. Launch Neolink:
   docker compose up -d

3. connect ffmpeg or a player to rtsp port

4. observe poor file descriptor behavior

-[/docker/neolink:#]- ps -ef | grep rtsp
root     1966709 1966679  0 20:29 ?        00:00:00 /bin/sh /entrypoint.sh neolink rtsp --config=/etc/neolink.toml
root     1966764 1966709  1 20:29 ?        00:00:00 neolink rtsp --config=/etc/neolink.toml
root     1966958 1700950  0 20:29 pts/5    00:00:00 grep --color=auto rtsp

-[/docker/neolink:#]- lsof -nPp 1966764 | wc -l
866

-[/docker/neolink:#]- lsof -nPp 1966764 | wc -l
906

-[/docker/neolink:#]- lsof -nPp 1966764 | wc -l
956

-[/docker/neolink:#]- lsof -nPp 1966764 | wc -l
996

-[/docker/neolink:#]- lsof -nPp 1966764 | wc -l
1048

-[~:#]- lsof -nPp 1966764 | tail
neolink 1966764 root *368u     sock    0,8      0t0 8356393 protocol: UNIX-STREAM
neolink 1966764 root *369u     sock    0,8      0t0 8356394 protocol: UNIX-STREAM
neolink 1966764 root *370u     sock    0,8      0t0 8356395 protocol: UNIX-STREAM
neolink 1966764 root *371u     sock    0,8      0t0 8356396 protocol: UNIX-STREAM
neolink 1966764 root *372u     sock    0,8      0t0 8358186 protocol: UNIX-STREAM
neolink 1966764 root *373u     sock    0,8      0t0 8358187 protocol: UNIX-STREAM
neolink 1966764 root *374u     sock    0,8      0t0 8356397 protocol: UNIX-STREAM
neolink 1966764 root *375u     sock    0,8      0t0 8356398 protocol: UNIX-STREAM
neolink 1966764 root *376u     sock    0,8      0t0 8356399 protocol: UNIX-STREAM
neolink 1966764 root *377u     sock    0,8      0t0 8356400 protocol: UNIX-STREAM

Expected behavior
A stable and reasonable usage of file descriptors

Versions
NVR software:
ffmpeg run out of cron, saving 15 minute segments (with a few seconds of overlap) ;)

Neolink software:
via docker image quantumentangledandy/neolink:latest

neolink  | [2025-08-03T21:10:36Z INFO  neolink] Neolink 6e05e7844b5b50f89787d30bffcbbd3471bfcfde release

Reolink camera model and firmware:

Model RLC-520A
Firmware Version v3.0.0.2839_23102301

[mooinglemur]

When the process runs out of fds, we start to see the behavior referenced by #340

gst_poll_read_control: assertion 'set != NULL' failed
gst_poll_write_control: assertion 'set != NULL' failed

Which I think it just neolink thrashing as it can't allocate fds, or rather more likely, the gstreamer lib cannot.

This continues until my ffmpeg process tries to open a new connection on the 15 minute mark, which then causes neolink itself to crash due to not having any available fds.

[mooinglemur]

Ok, I spoke too soon, it's also happening with 3 cameras, but it's not doing so right out of the gate.

It spins with the assertions until a new ffmpeg process tries to connect over rstp, at which point it crashes and is allowed to restart.

neolink  | (neolink:8): GStreamer-CRITICAL **: 22:00:21.490: gst_poll_write_control: assertion 'set != NULL' failed
neolink  | 
neolink  | (neolink:8): GStreamer-CRITICAL **: 22:00:21.490: gst_poll_write_control: assertion 'set != NULL' failed
neolink  | 
neolink  | (neolink:8): GStreamer-CRITICAL **: 22:00:21.490: gst_poll_read_control: assertion 'set != NULL' failed
neolink  | 
neolink  | (neolink:8): GStreamer-CRITICAL **: 22:00:21.490: gst_poll_read_control: assertion 'set != NULL' failed
neolink  | 
neolink  | (neolink:8): GStreamer-CRITICAL **: 22:00:21.504: gst_poll_write_control: assertion 'set != NULL' failed
neolink  | 
neolink  | (neolink:8): GLib-ERROR **: 22:00:21.522: Creating pipes for GWakeup: Too many open files
neolink  | Trace/breakpoint trap (core dumped)
neolink exited with code 133
neolink  | Running: neolink mqtt-rtsp --config=/etc/neolink.toml
neolink  | [2025-08-03T22:00:34Z INFO  neolink] Neolink 6e05e7844b5b50f89787d30bffcbbd3471bfcfde release
neolink  | [2025-08-03T22:00:34Z INFO  neolink::rtsp] Starting RTSP Server at 0.0.0.0:8554
neolink  | [2025-08-03T22:00:34Z INFO  neolink::rtsp] cam-street: Rtsp Starting
neolink  | [2025-08-03T22:00:34Z INFO  neolink::rtsp] cam-reareast: Rtsp Starting
neolink  | [2025-08-03T22:00:34Z INFO  neolink::rtsp] cam-rearsouth: Rtsp Starting

[mooinglemur]

Another update: this spiraling out of control seems to begin as soon as ffmpeg connects to neolink's rtsp port.

I don't think any of the previous reports of this "leak" problem have addressed massive amounts of open file descriptors, but I'm hoping this will point someone in the right direction.

[wafgo]

Hi @mooinglemur @QuantumEntangledAndy my PR here #373 should fix this issue