patch purpose//Re：[patch]fork: subprocess quit when parent died

Hi, ZhiDao.  If master dies often as you said, I believe community shell treat it as a bug and fix it ASAP.  Personally I won't meet it frequently. Only at when system OOM or user misoperation. Thanks.  ___ nginx-devel mailing list nginx-devel@nginx.org

Re: [PATCH] Mail: Support SASL EXTERNAL (RFC 4422)

Hello! On Sat, Oct 08, 2016 at 06:31:02PM +1100, Rob N ★ wrote: > # HG changeset patch > # User Rob N ★ > # Date 1475910300 -39600 > # Sat Oct 08 18:05:00 2016 +1100 > # Node ID 205f2148260460379f9b0889cdb8015994028c73 > # Parent 1606a817c1d48ed351f1dd7d9cb9c996e2c77b9a

patch purpose//Re：[patch]fork: subprocess quit when parent died

Hi, Maxim. When master OOM, system daemon program like supervisord will trying to pull it up. but it can’t be done because of worker binds the port. And i believe the master process shell handler all the resources. Slaves shell not exist on its own.  

Re: path purpose//Re：[patch]fork: subprocess quit when parent died

Hello! It's a common case that all the worker processes are still live while the master process isn't exist. So I think nginx should continue to work as Maxim said. Btw, we noticed that nginx.pid is deleted when we do the upgrade command. kill -USR2 nginx.pid; sleep(2); kill -HUP nginx.oldpid;

Re: path purpose//Re：[patch]fork: subprocess quit when parent died

Hello! On Thu, Oct 13, 2016 at 08:38:56AM +0800, 李林哲 wrote: > This patch is solving the problem that the sub process (worker > process) will not quit when master process quits on SIGKILL. > which will be done by OS (especially Linux) when system meet > OOM. Why do you think that worker

[patch]worker process: make sure to quit when master quits

# HG changeset patch # User lilinzhe # Date 1476321680 -28800 # Node ID d13daa14b1df9e04d7bf339c1669740edf19de0e # Parent 7cdf69d012f02a80c94d930b29c71847e203e4d6 worker process: make sure to quit when master quits when theres prctl(PR_SET_PDEATHSIG). make worker to use it. on

path purpose//Re：[patch]fork: subprocess quit when parent died

Thanks for reply. This patch is solving the problem that the sub process (worker process) will not quit when master process quits on SIGKILL. which will be done by OS (especially Linux) when system meet OOM. I've found a bug, and will send a new patch for comment.

Re: When to use --with-compat configure option?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-10-12 16:33, Maxim Dounin wrote: > [...] > > From package maintaining point of view it should be a good idea to > add the option to nginx builds. This will allow others to easily > compile dynamic modules to be loaded into nginx shipped

[njs] A fix in Array.slice() function.

details: http://hg.nginx.org/njs/rev/8046b999aaaf branches: changeset: 198:8046b999aaaf user: Igor Sysoev date: Wed Oct 12 19:08:57 2016 +0300 description: A fix in Array.slice() function. diffstat: njs/njs_array.c | 34 +-

question about how to use the ngx_radix_tree

Dear list, I am interested in using this data structure. Would it be possible to have a few usage examples of it? I looked in the nginx code via github but found only few usages and not very informative about how to use it properly. I am interested in those functions: ngx_radix_tree_t

Re: When to use --with-compat configure option?

Hello! On Wed, Oct 12, 2016 at 03:58:25PM +0200, Thomas Deutschmann wrote: > nginx-1.11.5 introduced a new configure option "--with-compat" however > I don't find any documentation regarding this option. > > Could you please give us some insight when you expect that this option > should be used

Re: [patch]fork: subprocess quit when parent died

Hello! On Wed, Oct 12, 2016 at 08:44:25PM +0800, 李林哲 wrote: > # HG changeset patch > # User lilinzhe > # Date 1476275566 -28800 > # Node ID 07d294d39cc6ec07769c1a72d5ee9b7da27b9ce1 > # Parent 7cdf69d012f02a80c94d930b29c71847e203e4d6 > fork: subprocess quit when parent died > >

When to use --with-compat configure option?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, nginx-1.11.5 introduced a new configure option "--with-compat" however I don't find any documentation regarding this option. Could you please give us some insight when you expect that this option should be used (especially from distribution

Re: slice module and upstream sent more data than specified in "Content-Length"

2016-10-12 14:09 GMT+02:00 Roman Arutyunyan : > Do you have this issue without slice? No, if I send a the same request that slice module would send to upstream through nginx without slice activated, I do not see the same errors > Anyway, it would be nice to see debug log Working

Re: freeing buffers after sending them

On Wednesday 12 October 2016 15:05:48 George . wrote: > Hi Valentin, > > Than you for your fast and correct reply. > > Yes, you are right, it was oversight that r->out->buf if taken from > pipe->pool, which is actually r->pool. > What if we pfree this bufs from r->pool? Who holds the reference

[patch]fork: subprocess quit when parent died

# HG changeset patch # User lilinzhe # Date 1476275566 -28800 # Node ID 07d294d39cc6ec07769c1a72d5ee9b7da27b9ce1 # Parent 7cdf69d012f02a80c94d930b29c71847e203e4d6 fork: subprocess quit when parent died diff -r 7cdf69d012f0 -r 07d294d39cc6 auto/os/linux --- a/auto/os/linux Tue Oct

Re: slice module and upstream sent more data than specified in "Content-Length"

Hi, On Tue, Oct 11, 2016 at 08:26:29PM +0200, Bjørnar Ness wrote: > Hello nginx-devel > > I am seeing lots of 'upstream sent more data than specified in > "Content-Length"' errors > when using nginx with proxy_cache and slice module. The relevant > nginx.conf settings are: > > > > slice 1m; >

Re: freeing buffers after sending them

Hi Valentin, Than you for your fast and correct reply. Yes, you are right, it was oversight that r->out->buf if taken from pipe->pool, which is actually r->pool. What if we pfree this bufs from r->pool? Who holds the reference after sending these buffers (except may be in NGX_THREADS version)?

RE: slice module and upstream sent more data than specified in "Content-Length"

Hi, Is your origin server something like Apache + mod_fastcgi + mod_deflate ? I did not see this specifically with Nginx but you may hit the same issue described here: https://ma.ttias.be/apaches-mod_fastcgi-mod_deflate-troubles/ Best regards, Thierry -Message d'origine- De :

Re: freeing buffers after sending them

On Wednesday 12 October 2016 13:22:08 George . wrote: > Hi all, > > What do you think about freeing buffers after being sent by send_chain? > Because we have a special case were we use 4 megabyte buffer instead of > nginx default 8 * 8 K and we found that these buffers are actually freed > after

freeing buffers after sending them

Hi all, What do you think about freeing buffers after being sent by send_chain? Because we have a special case were we use 4 megabyte buffer instead of nginx default 8 * 8 K and we found that these buffers are actually freed after request had been finished, so if there hundreds of slow downstream