Following up on https://stackoverflow.com/questions/14176089/system-command-line-max-length-in-perl, which say the max length for exec/command line arguments is controlled by ARG_MAX
.
So I want to increase such command line max length, and it seems recompiling the kernel is the only option. Fine. However my question is on the ARG_MAX
, because everyone is saying that it is the one that needs to be increased, but I read from http://www.in-ulm.de/~mascheck/various/argmax/#linux that,
ARG_MAX
is not used in the kernel code itself pre-2.6.23. Post Linux 2.6.23, ARG_MAX
is not hardcoded any more.
So is ARG_MAX
not used any more or not? How to increase the max length for exec/command line arguments then? because my command line max length is capped to some smaller value than I prefer.
Thanks
Best Answer
Since linux-2.6.23
ARG_MAX
is not necessarily a pre-determined constant, the total size for arguments is permitted to be up to 1/4 of the stack size (seeulimit -s
, stack size in kB; but/proc/1/limits
is more definitive) . However,ARG_MAX
is not just for the process arguments, it also contains the environment variables, which you may need to take into account.POSIX defines what
ARG_MAX
means, and an acceptable lower limit (_POSIX_ARG_MAX
4096). Its static value is (historically) available via a#define
in the system headers, and it's also set in the linux kernel headers. Its effective value is available bysysconf()
orgetconf ARG_MAX
from the command line.If you check the glibc headers (
sys/param.h
) you'll see this:That's from glibc-2.17, this appeared around 2.11 (2009), first support for this dates to 2.8 (2008), but prior to 2.14 (2011) there was a bug in the above logic which prevented it from working as expected. The intention is to make sure
ARG_MAX
is undefined if it's not a constant, so programs should rely onsysconf()
. (Even if it is defined it might only be a lower guaranteed limit, and programs should usesysconf()
to determine the variable upper limits, seesysconf(3)
)You can check what your C compiler sees with (
gcc
,bash
/zsh
syntax only):The above output is from an old system (2.6.27), which has the kernel support, but not the complete runtime (glibc support). If you see no
ARG_MAX
line then it is not a pre-determined limit, and you should use (sysconf)getconf ARG_MAX
:A useful way to check support is also:
That's from a linux-2.6.37/glib-2.13 system with the higher limits. Note the final line of output,
xargs
defaults (build time) to a "sensible" limit, probably in case any of the processes it starts are not capable of handling very large values. You can modify that at run-time with the-s
option. Also, if you have aulimit -s
in effect, those numbers may be lower. This should work correctly since findutils-4.3.9 (2007). See also: http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#Argument-list-too-longTo check perl:
The above is again from an old system, a new system should show:
To summarize:
ARG_MAX
), it should check forexec()
E2BIG
error codes instead, and should usesysconf(_SC_ARG_MAX)
if neededargc
,argc
, the environment area for run time use). This is typically done in libc (glibc).A problem combination is an updated (linux >=2.6.23) kernel, but missing or suspect glibc support (glibc<=2.14)
If you're running an older kernel, first make sure your vendor hasn't back-ported the feature. Otherwise you can in principle alter the kernel limit and recompile, but you may need to also modify at least some system headers or source code for working support.
Programs should be able to handle arbitrary values, but this may not always be the case: http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html