Problem solved, strangely enough the order in which my servers are
loaded
seams to trigger this error, it’s actually nothing to do with the
upstream
settings but forcing one of my server configs to be loaded last resolved
the
issue.
On Tue, Nov 16, 2010 at 01:16:25PM +0000, Phil B. wrote:
server 3.4.5.6;
Is this a bug?
Most likely you used backend2 somewhere in proxy_pass before
defining upstream backend2. This is not generally supported and
and shouldn’t be allowed, but happens to “work” (though with
several unexpected side effects) for now.
Attached patch makes sure such configuration like
server {
location / {
proxy_pass backend;
…
}
…
}
upstream backend {
…
}
will generate “upstream “backend” defined too late” error during
configuration parsing.
On Tue, Nov 16, 2010 at 03:02:00PM +0000, Phil B. wrote:
I had actually prefixed upstream and localhost 000 and everything else 100
to force them to load in the correct order.
On 1 particular domain it would throw that error unless it was loaded last,
hence just giving it a prefix 101 solved the issue.
Bit strange!
Addition prefixes isn’t going to do anything good as nginx doesn’t sort
included files (I assume you used something like “include
/path/*.conf”) and they are loaded in unspecified order (as
filesystem returns them).
You have to manually preserve correct order, i.e. use something
like
include /path/to/generic/includes/.conf;
include /path/to/virtual/hosts/.conf;
I had actually prefixed upstream and localhost 000 and everything else
100
to force them to load in the correct order.
On 1 particular domain it would throw that error unless it was loaded
last,
hence just giving it a prefix 101 solved the issue.
Bit strange!
Addition prefixes isn’t going to do anything good as nginx doesn’t
sort included files (I assume you used something like “include
/path/*.conf”) and they are loaded in unspecified order (as
filesystem returns them).
You have to manually preserve correct order, i.e. use something
like
include /path/to/generic/includes/.conf;
include /path/to/virtual/hosts/.conf;
Well that’s interesting. I was under the (wrong) impression that in
fact it operated like in Apache. Where there’s a 000-default vhost
config file in Debian that is a symlink created when enabling the
site.
I have a 000-default file that just returns a 444 when the Host header
doesn’t match any of the server_name directives. I guess that I should
be loading that file explicitly before all other.
include /etc/nginx/sites-enabled/000-default
include /etc/nginx/sites-enabled/[a-z]*
On Tue, Nov 16, 2010 at 06:32:19PM +0000, António P. P. Almeida wrote:
strange!
include /path/to/virtual/hosts/.conf;
include /etc/nginx/sites-enabled/000-default
include /etc/nginx/sites-enabled/[a-z]
Right?
Alternative solution is to use “listen … default;” (or “listen
… default_server;” which is the same) in a server which should
be default on a given socket.
On Tue, Nov 16, 2010 at 05:49:16PM +0300, Maxim D. wrote:
[…]
Most likely you used backend2 somewhere in proxy_pass before
defining upstream backend2. This is not generally supported and
and shouldn’t be allowed, but happens to “work” (though with
several unexpected side effects) for now.
Disregard this (and patch). Actually, the only thing which won’t
work as expected is an attempt to redefine unix socket with
upstream{} block.
