[nginx] dso

[Igor Sysoev]

On 27 Apr 2016, at 19:32, 洪志道 <hongzhidao at gmail.com> wrote:

> Get.
> In production, there may be some possibility with load_module directive.
> 1. add new module: load_module  modules/some_module.so;   [?]
> 2. remove exist load_module directive, just comment out.   [?]
> 3. directive not changed but the so file changed.   [kill -USR2 `cat nginx.pid`; sleep 2; kill -QUIT `cat nginx.pid.oldbin`]
> And how to deal with?

USR2/QUIT is online binary upgrade procedure:
http://nginx.org/en/docs/control.html#upgrade
And this procedure should be used to change and to unload modules.


-- 
Igor Sysoev
http://nginx.com

> 2016-04-28 0:08 GMT+08:00 Igor Sysoev <igor at sysoev.ru>:
> On 27 Apr 2016, at 18:51, 洪志道 <hongzhidao at gmail.com> wrote:
> 
>> Thanks for your reply.
>> 
>> Is it the only way to solve the problem?
> 
> This is a way to reload a module in production without service interruption.
> 
>> I think it will be common that developers try to use dso instead of static module.
> 
> Developers can simply stop and start nginx again.
> 
> -- 
> Igor Sysoev
> http://nginx.com
> 
>> Nginx offical site points out we could load in so modules using reload or restart, but it seems forget to instruct the details about reload.
>> And it's a great design, thanks again.
>> 
>> 2016-04-27 19:22 GMT+08:00 Igor Sysoev <igor at sysoev.ru>:
>> On 27 Apr 2016, at 12:10, 洪志道 <hongzhidao at gmail.com> wrote:
>> 
>>> Hi,
>>> 
>>> for example following config:
>>> 
>>> daemon  on;
>>> ...
>>> load_module  modules/ngx_http_test_module.so;
>>> ...
>>> 
>>> > start nginx
>>> > change ngx_http_test_module.c, then regenerate so file
>>> > kill -HUP pid
>>> 
>>> I found nginx still run the old so file (load first time), and how to work with new so file?
>>> 
>>> I tried .../sbin/nginx -s reload, It works as I expected. It seems there is some differences in 'kill -HUP' and 'sbin/nginx -s reload’;
>> 
>> kill -USR2 `cat nginx.pid`; sleep 2; kill -QUIT `cat nginx.pid.oldbin`
>> 
>> 
>> -- 
>> Igor Sysoev
>> http://nginx.com
> 
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
> 
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160427/629f6b08/attachment.html>