enable reuseport then only one worker is working?

Andrew Hutchings ahutchings at nginx.com
Tue Mar 1 14:43:07 UTC 2016

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 

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

More information about the nginx mailing list