Bug in the nginx-0.7.xx include .../conf.d/*.conf process ?

[Merlin]

I sometimes use NginX on Debian and maybe we really need to talk to Fabio
and Jose (the package maintainers in debian) as I don't see them post here
ever.

In my humble opinion there is no reason NginX's core should change from a
very useful (in terms of safety, debugging) feature to a less useful feature
only supporting an incomplete package.

The simplest debian-like nginx.conf is something like this:
(where N and M are appropriate numbers)
----
user www-data;
worker_processes N;
events {
  worker_connections M;
}

http {
  include mime.types;
  include conf.d/*.conf;
  include httpd.conf;
  include sites-enabled/*;
}
----

On Mon, Mar 23, 2009 at 1:56 AM, Mark Alan <varia at e-healthexpert.org> wrote:

> Maxim Dounin wrote:
>
>> This is not bug, it's by design.  And this allows to catch obvious
>> configuration errors easily - without even breaking working setup, since
>> nginx master process will refuse to reload configuration with bugs (and
>> hence old worker processes with correct configuration will continue to serve
>> requests).
>>
>
> I do think that the duplication check mechanism is very useful and among
> the strongest points of nginx. But I was not talking about that.
>
> nginx could still avoid breaking working setup by doing duplication checks
> and catch errors. It could have the best of both worlds by simply  doing
> duplication check AFTER reading all .conf files, but still giving precedence
> to .conf files in the priority directory /conf.d/.
>
> I am thinking of, at least, /etc/php5/conf.d, /etc/apt/apt.conf.d,
> /etc/mysql/conf.d, /etc/apache2/conf.d. They all work rather well and
> respect /conf.d/*.conf precedence without breaking program's internal
> integrity.
>
>  Also I should say that debian default config layout for nginx is rather
>> bad, since it provokes many configuration bugs.
>>
>
> So, the debian nginx package maintainer is sloppy.
> In your opinion what changes should be made to the Debian package to clean
> those bugs?
>
> > Some of them are easy to find thanks to duplication checks,
> > but some are really hard to find.
>
> Now, really helpful would be if you could provide us with a known list of
> those configuration bugs, in special those hard to find. Or, at least, point
> us to a web site were those configuration bugs are clearly listed for future
> reference.
>
>
> M.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20090323/1c2d0305/attachment.html>