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 B.R.~ 2016-08-30 19:22 GMT+08:00 Maxim Dounin <mdou...@mdounin.ru>: > Hello! > > On Tue, Aug 30, 2016 at 06:33:36PM +0800, 洪志道 wrote: > > > [...] > > > I found a coredump file generated on production. > > [...] > > > nginx.conf > > > > load_module modules/....; > > load_module modules/ngx_http_abc_module_3.so; # This module is in the > > last postion, the other modules seems right. > > > > And there is tiny detail. I generate so file named > > 'ngx_http_abc_module.so', then I copy as ngx_http_abc_module_3.so > > Note that when writing module *.so files care should be taken to > not modify contents of files currently loaded. E.g., "make > install" in nginx will first move an old file (if any) to > *.so.old, and then copy the new file. > > If you happened to modify an *.so file currently loaded, > segmentation fault is expected. Just using "cp" without moving an > old file first is known to cause segmentation faults as it > modifies contents of existing *.so files. > > -- > Maxim Dounin > http://nginx.org/ > > _______________________________________________ > nginx-devel mailing list > nginx-devel@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
