upgrading binary failed - execve - too long argument list
me at mheard.com
Wed Apr 28 22:57:28 UTC 2021
At-least on my system ARG_MAX depends on the size of ulimit.
# getconf ARG_MAX
# ulimit -s unlimited
# getconf ARG_MAX
Meaning no kernel recompilation should be necessary to adjust the maximum
On Thu, 29 Apr 2021 at 07:13, Maxim Dounin <mdounin at mdounin.ru> wrote:
> On Tue, Apr 27, 2021 at 12:35:58PM +0200, Charlie Kilo wrote:
> > Hi everyone,
> > i'm trying to upgrade an nginx-binary while running.
> > When i do kill -s USR2 <pid>, i get the following error in the logs..
> > 11:40:38 [alert] 52701#0: execve() failed while executing new binary
> > process "/opt/sbin/nginx" (7: Argument list too long)
> > Anybody knows what exactly is in those arguments ? We have ~ 20-55 worker
> > processes if that might be related..
> > nginx-version is 1.18.0, os: debian buster
> The only notable thing I can think of is the list of open
> listening sockets, which is passed in the NGINX environment
> variable to the new process.
> There should be plenty of space even with a lot of listening
> sockets though, given the default limit of 2M on Linux. Even with
> "listen ... reuseport", when a separate listening socket
> is created for each worker process, it does not look like the
> limit can be easily reached: 2M should be enough for about 300k
> listening sockets, so with 55 worker processes it is about 5k
> listening sockets with reuseport.
> How many listening sockets do you have? Do they use "listen ...
> reuseport" option? What "getconf ARG_MAX" and "ulimit -s" show on
> your system? Any 3rd party modules (and what "nginx -V" shows)?
> Maxim Dounin
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx