Transmission TCP Connection Limit Error

[anakin827]

Getting a listen queue overflow error, I believe it is being caused by my Transmission jail. Has anyone else experienced this? I'm currently running FreeNas 11 RC1. I've edited the /etc/sysctl.conf file both from command line and with vi to change the setting for kern.ipc.soacceptqueue to allow for 2048 connections, but this doesn't survive a reboot.

May 19 18:43:24 maverick kernel: sonewconn: pcb 0xfffff8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (138 occurrences)
May 19 19:02:16 maverick kernel: sonewconn: pcb 0xfffff8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (200 occurrences)
May 19 19:03:17 maverick kernel: sonewconn: pcb 0xfffff8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (209 occurrences)
May 19 19:04:17 maverick kernel: sonewconn: pcb 0xfffff8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (199 occurrences)
May 19 19:05:17 maverick kernel: sonewconn: pcb 0xfffff8035bef6740: Listen queue overflow: 193 already in queue awaiting acceptance (202 occurrences)

 

[anakin827]

Update, I've found the tunables in the FreeNas GUI which seems to have allowed me to make the changes for the main system

Partial output of netstat -Lan command

tcp4 0/0/2048 127.0.0.1.8542
tcp4 0/0/2048 127.0.0.1.8600
tcp4 0/0/2048 127.0.0.1.8500
tcp4 0/0/2048 127.0.0.1.8400

However when I go into my Transmission jail and run netstat -Lan I get the followng:

tcp4 0/0/128 192.168.0.20.12348
tcp6 0/0/128 *.51413
tcp4 0/0/128 *.51413
tcp4 0/0/128 *.9091

If I run sysctl kern.ipc.soacceptqueue it shows the following:

# sysctl kern.ipc.soacceptqueue
kern.ipc.soacceptqueue: 2048

Any ideas why the output of Netstat isn't reflecting the change to 2048?

 

[anakin827]

Bump.

 

[Joshua Parker Ruehlig]

I'm not sure how sysctl on the host affect the jail. But there is a place to enter sysctl for the jail.
Jails > Edit (the specific jail you care about) > Sysctls

Also, instead of editing sysctl.conf, you can edit FreeNAS host sysctls at...
System > Tunables

 

[anakin827]

I found the tunables and that how I edited Sysctl in the host system. However I tried putting the kern.ipc.soacceptqueue=2048 for the jail but that doesn't get accepted. Not sure what the proper sysctl command would be to expand the queue size within the jail.

 

[dlavigne]

To confirm: you restarted both the FreeNAS system and the jail after setting that Tunable?

If so, it sounds like an upstream netstat or jail bug as kernel sysctls are meant to be set on the host and inherited by the jails. If you decide to create an upstream bug report at https://bugs.freebsd.org/bugzilla/, post the issue number here.

 

[anakin827]

Correct, I have rebooted numerous times since making the change. I'll file a bug report. Thanks for the info!

 

[anakin827]

Here is the bug report link: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219655

 

[jbeez]

2019, still having this. Has anyone figured this out yet, or is a patch that hasn't been merged in the only recourse at this time

 

[Jecvay]

2021, still having this.

 

[dakta]

2022, still an issue. I poked into the Transmission source and was able to determine that they're not hard-coding a listen queue limit: https://github.com/transmission/tra...fd9cc3e51b843e3f4/libtransmission/net.cc#L471

Code:

    /* Listen queue backlog will be capped to the operating system's limit. */
    if (listen(fd, INT_MAX) == -1)

So, something else is going on here. I have the tunable set on the host system (and have definitely rebooted), and inside the jail it shows as expected:

Code:

root@transmission:~ # sysctl kern.ipc.soacceptqueue
kern.ipc.soacceptqueue: 1024

However, Transmission only uses 128:

Code:

root@transmission:~ # netstat -LaAn
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb            Proto Listen                           Local Address
fffffe014da73950 tcp6  0/0/128                          *.51414
fffffe014da74000 tcp4  0/0/128                          *.51414
fffffe014da74438 tcp4  0/0/128                          *.80

Even the RPC/web server is only binding maxqlen of 128.

Pulling from the linked bug, this is indeed a bug in FreeBSD which is caused by the sysctl not being VNET-aware: it literally doesn't apply to jails. Comment 3

kern.ipc.soacceptqueue is SYSCTL_PROC defined in sys/kern/uipc_socket.c without CTLFLAG_VNET, so it is not VIMAGE/VNET-aware currently.

Very sad.