we have a bunch of servers which are configured 100% equal expect of
host
specific settings like ip address in the listener using chef/puppet.
Nginx
seems to read include / config files not in the same order on each
server.
For example we haven’t defined a default vhost on each server… so
nginx
uses the first loaded file which is exampleA.com on server 1 and exampleB.com on server 2.
Furhtermore we use the upstream check status module, the status page is
randomly ordered at each server…
Is it possible to configure nginx to read config in the alphabeticial
order?
On Wed, Nov 28, 2012 at 07:48:27PM +0800, Joshua Z. wrote:
For example we haven’t defined a default vhost on each server… so nginx
@Maxim:
Would you please consider to apply this patch to the trunk? Thanks in
advance.
I’ve already proposed removing GLOB_NOSORT to Igor a while ago.
His position on this is to keep this in sync with Windows version
where there is no sort guaranties.
I’ve already proposed removing GLOB_NOSORT to Igor a while ago.
His position on this is to keep this in sync with Windows version
where there is no sort guaranties.
[…]
Can’t we just pass that as a config option so that the configure script
detects the build environment and if were on *NIX the sorting is enabled?
I’ve already proposed removing GLOB_NOSORT to Igor a while ago.
His position on this is to keep this in sync with Windows version
where there is no sort guaranties.
this just can be described in documentation as drawback
of windows version of nginx, as many other “Known issues”
and limitations at nginx for Windows
because the UNIX version of nginx is the major and main stream.
so the best possible capabilities must be present in UNIX version,
not in windows one. and windows version must be compatible with
UNIX version, if this is possible.
now - capabilities of mainstream UNIX version artificially limited
to be “compatible” with even not-production-ready windows version.
this is very strange and unexpected and confusing
for users of mainstream UNIX/Linux version of nginx
(and this is more than 99% of all use cases of nginx)
for example, windows 7 not support cache module
and many other modules - but this is not reason
for remove this feature from UNIX version of nginx.
P.S.
similar example: method java.io.File.renameTo
(function “rename”)works differently on Windows and UNIX,
this is “Known issues” and can’t be avoided in any case.
btw, similar “rename bugs” and incompatibilities also
must be presented also in windows/unix version of nginx
I’ve already proposed removing GLOB_NOSORT to Igor a while ago.
His position on this is to keep this in sync with Windows version
where there is no sort guaranties.
[…]
Can’t we just pass that as a config option so that the configure script
detects the build environment and if were on *NIX the sorting is
enabled?
On Wed, Nov 28, 2012 at 01:27:04PM +0100, Antonio P.P. Almeida wrote:
Hello!
I’ve already proposed removing GLOB_NOSORT to Igor a while ago.
His position on this is to keep this in sync with Windows version
where there is no sort guaranties.
[…]
Can’t we just pass that as a config option so that the configure script
detects the build environment and if were on *NIX the sorting is enabled?
The codepath in question is unix-only, the question is about user
experience which will be different on unix and win32 with
GLOB_NOSORT removed on unix.
Right now one can’t rely on wildcard include ordering, and this is
consistent for all platforms supported. And “listen … default”
should be used to mark default server if one uses wildcard include
to include multiple server blocks listening on the same some
ip:port. With the GLOB_NOSORT removed the behaviour will be
different on unix (included files will be sorted) and win32
(included files are not guaranteed to be sorted), which is
considered bad.
(I personally think that GLOB_NOSORT should be removed anyway.
I’ll talk to Igor again about this.)
On Wed, Nov 28, 2012 at 06:15:50PM +0400, Maxim D. wrote:
[…]
should be used to mark default server if one uses wildcard include
to include multiple server blocks listening on the same some
ip:port. With the GLOB_NOSORT removed the behaviour will be
different on unix (included files will be sorted) and win32
(included files are not guaranteed to be sorted), which is
considered bad.
(I personally think that GLOB_NOSORT should be removed anyway.
I’ll talk to Igor again about this.)
I’ve discussed this with Igor, and this time he finnally approved
removing GLOB_NOSORT. Committed,