enable reuseport then only one worker is working?

[Jim Ohlstein]

Hello,

On 3/1/16 8:34 AM, Andrew Hutchings wrote:
> Hi Jim,
>
> On 01/03/16 13:10, Jim Ohlstein wrote:
>> Hello,
>>
>> On 2/28/16 11:22 PM, Валентин Бартенев wrote:
>>> On Sunday 28 February 2016 08:52:12 meteor8488 wrote:
>>>> Hi All,
>>>>
>>>> I just upgrade Nginx from 1.8 o 1.9 on my FreeBSD box.
>>> [..]
>>>> Did I miss anything in the configuration? or for a busy server, it's
>>>> better
>>>> to use accept_mutex instead of reuseport?
>>>>
>>> [..]
>>>
>>> In FreeBSD the SO_REUSEPORT option has completely different behavior
>>> and shouldn't be enabled in nginx.
>>>
>>
>> Should the configruation option then be disabled or silently ignored in
>> FreeBSD at this time?
>
> It would be difficult to selectively ignore operating systems based on
> how this function is supported. Especially if that support changes over
> time.

I don't claim to know how "difficult" that would be, but with all the 
extremely talented coders in the Nginx group, I would think that 
"difficult" would not be a barrier to "doing it right". If OS support 
changes, nginx can change. Something tells me that with a FreeBSD Core 
Team member on the Nginx payroll, if this OS feature changes, it'll 
filter through to the people who write the code.

If I choose to try "use kqueue" on a system that does not support that 
event method, I am hoping nginx would either tell me by refusing to 
start, or ignore my stupidity. Similarly, if I attempt to enable 
"reuseport" on Solaris or Windows which (I guess) do not support 
SO_REUSEPORT, nginx will inform me. I know this happens on FreeBSD with, 
for instance, aio. If aio is not built in to the kernel (it is not by 
default), or specifically loaded, nginx gives an error and won't start. 
In the case of SO_REUSEPORT, the OS call has virtually the opposite of 
the desired effect.

If a directive has the potential for significantly bad consequences, it 
should be spat out during config testing with at least a warning.

>
> I believe that DragonFly BSD for example supported the method most BSDs
> use originally.
>
> In the FreeBSD pattern it is designed to bleed off connections to one
> service as another comes up. Such as a binary upgrade. The last socket
> listener always gets new connections. This is almost the exact opposite
> of what Linux does with the option (DragonFly is somewhere in the
> middle). I'm personally not a BSD expert so can't say which other BSD
> operating systems use the same method as FreeBSD and even which ones do
> not even have a SO_REUSEPORT option.
>
> Documentation is probably the best option for now and we have tried to
> make it clear which operating systems do support this feature.


I'm not trying to make an excuse for not reading the documentation, 
which is clear and is exactly why I have not tested this feature on 
FreeBSD. Rather, I'm suggesting a more rigorous approach to config parsing.


-- 
Jim Ohlstein


"Never argue with a fool, onlookers may not be able to tell the 
difference." - Mark Twain