nginx dso coredump
洪志道
hongzhidao at gmail.com
Tue Aug 30 15:25:26 UTC 2016
Hello.
So is it not allowed that we reload a configuration after change
load_module directive?
But it seems probably happened that others guys reload nginx, since they
don't know
whether load_module changes.
I mean we should upgrade after change so files, but it's easy to get a
segmentation fault
if some other guy run a reload command at that time.
B.R.
2016-08-30 21:05 GMT+08:00 Maxim Dounin <mdounin at mdounin.ru>:
> Hello!
>
> On Tue, Aug 30, 2016 at 08:46:42PM +0800, 洪志道 wrote:
>
> > Thanks a lot for your reply.
> >
> > First, we want to manage the module versions, such as
> > ngx_http_abc_module_1.so, ngx_http_abc_module_2.so.
> > Maybe you can share a better way.
> >
> > Second:
> > "Note that when writing module *.so files care should be taken to
> > not modify contents of files currently loaded" -- I get, but we didn't.
> >
> >
> > The above problem I described is:
> >
> > load_module modules/ngx_http_abc_module_2.so; # it runs well before
> > upgrading
> >
> >
> > Then we upgrade module named ngx_http_abc_module_3.so
> > [ make install: generate new file ngx_http_abc_module.so; cp
> > ngx_http_abc_module.so ngx_http_abc_module_3.so]
> >
> > Then change config
> >
> > load_module modules/ngx_http_abc_module_3.so;
> >
> > Finally we upgrade nginx: -USR2 && sleep && -QUIT old
>
> As long as you use upgrade via USR2 signal this process should be
> fine. Note though, that if you'll try to reload a configuration
> instead of upgrade, you'll likely get a segmentation fault as
> well, since there will be multiple conflicting symbols for your
> module loaded at the same time.
>
> Overral I would recommend you to avoid using such distinct *.so
> names as it looks very fragile.
>
> If you want to store module version somewhere, consider just
> adding a symbol with appropriate information to the module itself.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> 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/20160830/ab8e8ef7/attachment.html>
More information about the nginx-devel
mailing list