Re: [ANN] OpenResty 1.25.3.2 released

Now that there is a patch out could you please share more information on those "specific circumstances"? It looks to me that luajit2 does not support SSE4.2 whereas agentzh's fork does. And this is what has been disabled in this release. Is this an interim release while the cause is investigated o

Re: nginx taking too long to respond

Alejandro, Not all up in Lua is non blocking. In fact many libraries for file ok are blocking. I would check that Also technically the engine (Lua script) processing is blocking and that can also be an issue if there is heavy processing . Hope that helps, Mathew On Mon, 19 Jul 2021, 10:26 pm m

Re: QUIC and HTTP/3 roadmap blog post

s certainly. I can think of a couple ways it could be architected especially now you have that ebpf packet router. Regards, Mathew On Tue, 13 Jul 2021 at 23:18, Vladimir Homutov wrote: > > On Tue, Jul 13, 2021 at 06:55:14PM +1000, Mathew Heard wrote: > > Hi Maxim, > > > > R

Re: QUIC and HTTP/3 roadmap blog post

Hi Maxim, Really interesting read. Do you have any plans for resolving the SIGHUP causes session closure issues that currently exist with nginx-quic? The closure of long lived connections has been a thorn in the side of people doing HTTP/1.1 web sockets (and probably HTTP/2 push) for many years.

Re: upgrading binary failed - execve - too long argument list

Maxim, Out of curiosity I checked some of my servers with "ss -l -t -p | grep nginx | wc -l" I'm at 15k at most. Large numbers of worker processes make it relatively easy to hit the ~20k limit it seems. With Regards, Mathew On Wed, 5 May 2021 at 01:53, Maxim Dounin wrote: > Hello! > > On Fri,

Re: upgrading binary failed - execve - too long argument list

At-least on my system ARG_MAX depends on the size of ulimit. # getconf ARG_MAX 2097152 # ulimit -s unlimited # getconf ARG_MAX 4611686018427387903 Meaning no kernel recompilation should be necessary to adjust the maximum argument space. On Thu, 29 Apr 2021 at 07:13, Maxim Dounin wrote: > Hello

Re: Nginx 1.19

Sad but probably due to HTTP/3, a long anticipated feature that's anything but simple. On Mon, 4 May 2020 at 18:27, Flinou wrote: > Hello, > > I know that, usually, mainline versions are supposed to be released the > month after the stable one. However, based on > https://trac.nginx.org/nginx/ro

Re: Print current running connections in nginx

This is a snippet from something I was experimenting with. I can't recall it actually worked, but it might help for a start. Good Luck. ngx_cycle_t *cycle for (i = 0; i < cycle->connection_n; i++) { c = &conns[i]; if (c->fd == (ngx_socket_t) -1 || c->idle || c->listening) continue; hlc = (

Re: Print current running connections in nginx

Sachin, AFAIK Not easily. Each worker only knows about their own connections. You would need to build a module using a shared memory zone to track connections. Regards, Mathew On 16/04/2020, sachin.she...@gmail.com wrote: > Hi, > > Status module prints the count of active connections. > > Is th

Re: Print current running connections in nginx

Sachin, AFAIK Not easily. Each worker only knows about their own connections. You would need to build a module using a shared memory zone to track connections. Regards, Mathew On 16/04/2020, sachin.she...@gmail.com wrote: > Hi, > > Status module prints the count of active connections. > > Is th

Re: Nginx Brunzip

ut the filter system. Regards, Mathew On Thu, 16 Apr 2020 at 03:12, Maxim Dounin wrote: > Hello! > > On Wed, Apr 15, 2020 at 10:21:09AM +1000, Mathew Heard wrote: > > > Hi all, > > > > I'm the maintainer of an open source module ngx_brunzip_module ( > >

Re: Nginx Brunzip

Disregard * 2 I understand now. On Thu, 16 Apr 2020 at 13:14, Mathew Heard wrote: > Disregard the previous email, there was a typo there. > > Maxim, > > I'm doing line by line documentation in my module. I hope by doing this I > will get a good understanding of what is

Re: Nginx Brunzip

em (I will however check with this mailing list to see if anyone has an issue with my descriptions). While doing this I noticed that ctx->busy does not appear to ever be true in your gunzip module. Am I missing something here? Regards, Mathew On Thu, 16 Apr 2020 at 13:11, Mathew Heard wrote:

Re: Nginx Brunzip

ee if anyone has an issue with my descriptions). While doing this I noticed that ctx->flush does not appear to ever be true in your gunzip module. Am I missing something here? Regards, Mathew On Thu, 16 Apr 2020 at 10:49, Mathew Heard wrote: > Maxim, > > Which clause of the 2 clause

Re: Nginx Brunzip

there was more. Regards, Mathew On Thu, 16 Apr 2020 at 03:12, Maxim Dounin wrote: > Hello! > > On Wed, Apr 15, 2020 at 10:21:09AM +1000, Mathew Heard wrote: > > > Hi all, > > > > I'm the maintainer of an open source module ngx_brunzip_module ( > > http

Nginx Brunzip

Hi all, I'm the maintainer of an open source module ngx_brunzip_module ( https://github.com/splitice/ngx_brunzip_module/ ). Effectively the same as the gunzip module (and based off that source) but with Br

Re: All I want for easter is a working module

st of times, the world is challenging. Currently, it’s not so > good. You’ll attract more bees with honey. > > > > On Apr 11, 2020, at 8:58 PM, Mathew Heard wrote: > > > > J.R, > > > > You won't find it publicly as all it is a testing module with the goal

Re: All I want for easter is a working module

J.R, You won't find it publicly as all it is a testing module with the goal of establishing a working timer. If you want the source code for it you need only ask. Here you go. /* * Copyright (C) Mathew Heard. */ #include #include #include #include #define NGX_HTTP_SLOW_INTERVAL

All I want for easter is a working module

Could anyone help me out with the problem here? ngx_module_t ngx_http_slow_module = { NGX_MODULE_V1, &ngx_http_slow_module_ctx, /* module context */ ngx_http_slow_commands, /* module directives */ NGX_HTTP_MODULE, /* module type */ NULL, /* init master */ NULL, /* init module */ ngx_http_slow_init

Fwd: Google QUIC support in nginx

Hey nginx team, How does the roadmap now look given the Cloudflare Quiche "experiment" release? Is QUIC/HTTP3 still scheduled for mainline? On Fri, 31 May 2019 at 16:54, George wrote: > Roadmap suggests it is in Nginx 1.17 mainline QUIC = HTTP/3 > https://trac.nginx.org/nginx/roadmap :) > > Pos

Re: Google QUIC support in nginx

ver websites, applications, and APIs. This is a significant undertaking, but likely to arrive during the NGINX 1.17 development cycle From: https://www.nginx.com/blog/nginx-1-16-1-17-released/ On Sat, Jun 1, 2019 at 10:53 PM Mathew Heard wrote: > It is nice to see that confirmation :) > > On

Re: Google QUIC support in nginx

It is nice to see that confirmation :) On Fri, May 31, 2019 at 4:54 PM George wrote: > Roadmap suggests it is in Nginx 1.17 mainline QUIC = HTTP/3 > https://trac.nginx.org/nginx/roadmap :) > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?2,256352,284367#msg-284367 > > __

Re: Google QUIC support in nginx

Hey nginx team, As I understand it QUIC support is road mapped for this year? Any chance of some confirmation, or any information that can be made available? Regards, Mathew On Fri, Jan 30, 2015 at 6:28 PM jtan wrote: > This would be interesting. But I guess we would need to wait. > > On Fri,

Fwd: CAP_NET_ADMIN

I have also tried: InheritableCapabilities=CAP_NET_BIND_SERVICE CAP_NET_ADMIN CAP_SETGID CAP_SETUID CAP_SYS_RESOURCE and various other options without avail. -- Forwarded message -- From: Mathew Heard Date: Wed, Oct 12, 2016 at 9:01 PM Subject: CAP_NET_ADMIN To: nginx

CAP_NET_ADMIN

Hi All, I am stuck trying to get my nginx service which is launched via SystemD to give CAP_NET_ADMIN to its workers (required for IP_TRANSPARENT). I have tried /etc/security/capability.conf & setcap. SystemD has the permission whitelisted: CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_ADMI