jails: detect exited on signal 6?

[MisterE2002]

I am running a Transmission jail with a lot of torrents.
The Freenas host log is flooded with messages:

kernel: sonewconn: pcb 0xfffff8013c482570: Listen queue overflow: 193 already in queue awaiting acceptance (158 occurrences)
kernel: sonewconn: pcb 0xfffff8013c482570: Listen queue overflow: 193 already in queue awaiting acceptance (162 occurrences)
kernel: sonewconn: pcb 0xfffff8013c482570: Listen queue overflow: 193 already in queue awaiting acceptance (153 occurrences)
kernel: sonewconn: pcb 0xfffff8013c482570: Listen queue overflow: 193 already in queue awaiting acceptance (193 occurrences)
kernel: sonewconn: pcb 0xfffff8013c482570: Listen queue overflow: 193 already in queue awaiting acceptance (140 occurrences)
kernel: sonewconn: pcb 0xfffff8013c482570: Listen queue overflow: 193 already in queue awaiting acceptance (120 occurrences)
kernel: pid 7681 (transmission-daemon), jid 9, uid 921: exited on signal 6

At some time it will terminate the process. I suppose those overflow messages are the cause?

2 questions:

1:
Can i increase those queues? Changed the tunables in Freenas but it does not seem to do anything
kern.ipc.soacceptqueue 8192
kern.ipc.somaxconn 4096
My Qotom pfsense router does not seem to have any troubles keeping track.

2:
Can and should FreeNAS detect those "exited on signal 6" crashes and inform (mail) the user?
I think the difficulty is how to know what process is in the jail to monitor?
Meaning of signal6 on: https://lists.freebsd.org/pipermail/freebsd-questions/2004-April/042665.html

 

[anodos]

What version of FreeNAS?

listen(2)

www.freebsd.org

It's not guaranteed that (1) the listen queue overflow is specifically related to transmission-daemon and (2) the particular listen() call uses the value of kern.ipc.soacceptqueue for its backlog, often the backlog is hard-coded to "5" in applications (or SOMAXCONN) at compile-time. There is a somewhat obscure FreeBSD behavior where you can specify "-1" as the backlog, and then the application will take use the value of kern.ipc.soacceptqueue for the backlog value in listen(2) calls. Adjusting this though would tracking down the offending application and fixing it.

The transmission core file might be useful if you recompile transmission-daemon with debug flag. Otherwise, you could possibly try adjusting your jail to use an IP alias rather than doing vnet (my experience is these tend to scale better).

 

[MisterE2002]

FreeNAS-11.3-U4.1
pretty convinced they are related. After the termination of the pid those overflow messages stop.
I have changed kern.ipc.soacceptqueue to -1 for now. Lets wait and see.

All my jails are running on port 80 with DHCP based on MAC.
VNET and BPF are required if i want to use DHCP. If i also disable DHCP and assign it directly to igb0 or igb1 i see the freenas GUI on that IP.

 

[anodos]

FreeNAS-11.3-U4.1
pretty convinced they are related. After the termination of the pid those overflow messages stop.
I have changed kern.ipc.soacceptqueue to -1 for now. Lets wait and see.

No. The place to set the -1 is in the compiled code for the application (if it makes a call to listen(2)). This means potentially patching the port. That said, increasing backlog can be helpful for getting over sudden bursts in load. If this is constant, then you'll just end up shifting the problem somewhere else.

 

[p30n]

I've got the exact same problem now with transmission.
Have had the overflow messages for a long time, I know it is coming from transmission but I have not found any solution to it and it still runs well.
Until last week when I updated all my jails to the most recent patch FreeNAS-11.3-U4.1
Now I am also getting the "exited on signal 6" for transmission-daemon every other day or so and I have to restart the daemon from the jail or restart jail completely.

If you have any idea what is causing this exit signal 6 and what solution could be, please let me know.