enable reuseport then only one worker is working?

[Andrew Hutchings]

On 01/03/16 14:23, Jim Ohlstein wrote:
> 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.

This would be more a case of effort / payoff. I'm not saying it isn't 
technically possible. But effort may be better spent implementing new 
features people have been asking for (we have some kick-ass stuff 
upcoming). Rather than implementing an OS kernel version detection with 
blacklist.

> 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.

Comparing it to kqueue isn't quite the same. On operating systems that 
do not support SO_REUSEPORT (including older Linux kernels) you will not 
be able to use the option at all. The problem here is FreeBSD has the 
option, it just has a different behaviour. I'm not even sure it is 
possible to detect in a build system without maintaining a blacklist.

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

I have mixed feelings on this. I believe for a majority of users this 
isn't a problem so users will see a warning that could concern them when 
in reality in a majority of cases it doesn't affect them.

Since it isn't enabled by default a user would have to research and make 
a conscious choice to turn it on. I would hope at this point the user 
would have made an informed decision when enabling tuning directives.

Kind Regards
-- 
Andrew Hutchings (LinuxJedi)
Technical Product Manager, NGINX Inc.