Re: Already loaded NGINX modules
Hello! On Thu, Feb 11, 2016 at 02:33:43PM -0800, Piotr Sikora wrote: > Hey Yichun, > > > Currently when an NGINX module is statically linked against the NGINX > > binary, the load_module directive bails out the server startup with > > the error message "module already loaded" (or something like that). > > Hopefully we can make this a nonfatal error (or provide an option to > > make it nonfatal) because we can have more portable nginx.conf for > > distributing NGINX-based applications. > > I disagree, because this would lead to unexpected behavior (since > statically linked module can be slightly different from the dynamic > module). > > Which version should be used at runtime in your non-fatal scenario and why? +1. If there is no need to load a module - there should be no load_module directive in the configuration. Everything else is likely to cause confusion. This is very similar to duplicate directives in configuration - and duplicate directives are rejected by nginx, for the same reasons. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Already loaded NGINX modules
Hello! On Fri, Feb 12, 2016 at 08:50:25AM -0800, Yichun Zhang (agentzh) wrote: > Hello! > > On Fri, Feb 12, 2016 at 3:42 AM, Maxim Dounin wrote: > > If there is no need to load a module - there should be no > > load_module directive in the configuration. Everything else is > > likely to cause confusion. > > The problem is that when we prepare nginx configurations for others, > we may have no idea how about how a particular set of modules are > built on the user side. As already pointed out, to properly write a configuration in many cases you have to know not only a set of modules, but also particular module versions. I don't think that what you are trying to do can be solved by introducing some "tolerant loading". Instead, you'll introduce confusion for normal users - and you'll still have the same problem with "configurations for others". > > This is very similar to duplicate directives in configuration - > > and duplicate directives are rejected by nginx, for the same > > reasons. > > Not really similar because the nginx configuration writer definitely > knows if he uses duplicate directives in his own nginx.conf but he can > hardly know how the nginx binary on the user side is built since > nginx.conf has no such information nor has a way to detect it in > nginx.conf itself. The question here is where you draw a line. If you assum that the administrator controls full nginx.conf configuration, but has no idea about modules loaded into nginx installed - well, it's may be not very similar. But if you'll assume that the administrator uses some pre-defined configuration snippets he cannot change - this case becomes exactly the same. -- Maxim Dounin http://nginx.org/ ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Already loaded NGINX modules
Hello! On Thu, Feb 11, 2016 at 3:29 PM, Piotr Sikora wrote: > > That doesn't really answer my question: which version (statically > linked or dynamic) of the module should we use at runtime if both are > present... and why? > For portable NGINX-based applications, for example, we only want to ensure that some modules are *present*, like ngx_http_lua_module, and we do not care about whether it is linked statically or dynamically. We are only concerned about its presence. If the modules we need are not statically linked, we want to dynamically load them. It's this simple :) I don't think it's reasonable to use a dynamic version of a module if it is already statically linked, is it? Best regards, -agentzh ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Already loaded NGINX modules
Hello! On Thu, Feb 11, 2016 at 2:33 PM, Piotr Sikora wrote: > I disagree, because this would lead to unexpected behavior (since > statically linked module can be slightly different from the dynamic > module). > > Which version should be used at runtime in your non-fatal scenario and why? We don't have version numbers in the DSO file names anyway :) And we can issue warnings to error.log, even with a high log level. Best regards, -agentzh ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Already loaded NGINX modules
Hello! On Thu, Feb 11, 2016 at 3:16 PM, Yichun Zhang (agentzh) wrote: > We don't have version numbers in the DSO file names anyway :) And we > can issue warnings to error.log, even with a high log level. > Or with an explicit option to the load_module directive, as in load_module ngx_http_lua_module.so duplicate=ignore; What about this? Begards, -agentzh Regards, -agentzh ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Already loaded NGINX modules
Hey Yichun, > Or with an explicit option to the load_module directive, as in > > load_module ngx_http_lua_module.so duplicate=ignore; > > What about this? That doesn't really answer my question: which version (statically linked or dynamic) of the module should we use at runtime if both are present... and why? Best regards, Piotr Sikora ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Already loaded NGINX modules
Hi guys! Currently when an NGINX module is statically linked against the NGINX binary, the load_module directive bails out the server startup with the error message "module already loaded" (or something like that). Hopefully we can make this a nonfatal error (or provide an option to make it nonfatal) because we can have more portable nginx.conf for distributing NGINX-based applications. Thanks for your attention! Best regards, -agentzh ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
Re: Already loaded NGINX modules
Hey Yichun, > Currently when an NGINX module is statically linked against the NGINX > binary, the load_module directive bails out the server startup with > the error message "module already loaded" (or something like that). > Hopefully we can make this a nonfatal error (or provide an option to > make it nonfatal) because we can have more portable nginx.conf for > distributing NGINX-based applications. I disagree, because this would lead to unexpected behavior (since statically linked module can be slightly different from the dynamic module). Which version should be used at runtime in your non-fatal scenario and why? Best regards, Piotr Sikora ___ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
