Listen queue guestion

[Bram Van Steenlandt]

Hi,

I had not considered the queue size in python/twisted, stupid, I know.
I was also asuming I was running into some sysctl limit because of the 
dmesg error (and the information I found online).

Now it works (the queue size is 50 by default), from what I can see/test 
it works like this:
I can set the queue size larger but setting it larger than sysctl 
kern.ipc.somaxconn has no point.
The fact that you get the dmesg message doesn't mean the sysctl is set 
too low, it's just something freebsd detects.

I think the connect/disconnectloop I was testing with just runs slower 
on the linux machine thus avoiding the problem.
On freebsd if I connect & disconnect in a loop (for testing) the number 
of connection goes up (probably because it's not really closed yet when 
I do close).

The handbook does say:
The |kern.ipc.somaxconn| sysctl(8) 
<http://www.FreeBSD.org/cgi/man.cgi?query=sysctl&sektion=8> variable 
limits the size of the listen queue for accepting new |TCP| connections.
https://www.freebsd.org/doc/handbook/configtuning-kernel-limits.html

Thx
Bram




op 16-09-14 10:08, Adrian Chadd schreef:
> Hm, ok. It's a UNIX domain socket. I kinda thought those also obeyed the sysctl.
>
> The sysctl has to be set -before- listen() is called.
>
> Also, in BSD, if the listen queue parameter to listen() is < 0, it
> defaults to the sysctl maximum.
>
>
> -a
>
>
> On 14 September 2014 23:44, Bram Van Steenlandt <bram at diomedia.be> wrote:
>> Hi,
>>
>> I use python, here the parameters are (socket.AF_UNIX,socket.SOCK_STREAM)
>>
>> Bram
>> op 14-09-14 23:05, Adrian Chadd schreef:
>>
>>> Hi!
>>>
>>> What kind of sockets is it specifically using?
>>>
>>>
>>> -a
>>>
>>>
>>> On 14 September 2014 12:27, Bram Van Steenlandt <bram at diomedia.be> wrote:
>>>> Hi,
>>>>
>>>> I'm porting an plc automation system to freebsd and while doing so I got
>>>> errors like these:
>>>> sonewconn: pcb 0xfffff8000cecc870: Listen queue overflow: 76 already in
>>>> queue awaiting acceptance
>>>>
>>>> With the help of netstat I've found the problem, 2 programs communicate
>>>> with
>>>> ipc file like sockets and the "client" was connecting too fast (it was
>>>> connecting and disconnecting in a small for loop).
>>>>
>>>> Still, on linux this worked and there will be cases where I may bump in
>>>> to
>>>> this limit again (a lot of different programs communicate with one master
>>>> program over ipc).
>>>>
>>>> I've found kern.ipc.somaxconn but this seems to be only for TCP
>>>> connections.
>>>>
>>>> Is there a sysctl or kernel parameter that allows me to set this queue a
>>>> bit
>>>> larger ?
>>>>
>>>> Thx
>>>> Bram
>>>>
>>>> _______________________________________________
>>>> freebsd-questions at freebsd.org mailing list
>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>>>> To unsubscribe, send any mail to
>>>> "freebsd-questions-unsubscribe at freebsd.org"
>>> _______________________________________________
>>> freebsd-questions at freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>>> To unsubscribe, send any mail to
>>> "freebsd-questions-unsubscribe at freebsd.org"
>>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"