Linux 在chroot中，execvp（）返回；“参数列表太长”；

我在chroot中运行大量命令时遇到问题。命令本身由Makefile触发，因此错误为：

make: execvp: /bin/sh: Argument list too long

我确实进行了调查，通过查看make的源代码，我了解到它通过libc提供的execvp（）创建了一个作业（我看到该命令被传递为“/bin/sh”“-c”“…我的参数”）。 所以我查看了libc源代码，基本上它看起来有一个由ARG_MAX定义的限制，但是最近它没有被使用，正如代码所说：

/* Legacy value of ARG_MAX.  The macro is now not defined since the
   actual value varies based on the stack size.  */
#define legacy_ARG_MAX 131072

因此，它认为我需要通过以下方式更改堆栈大小：

ulimit -s VALUE

所以我比较了chroot外部的值，并在chroot内部设置了一个更大的值。然而同样的结果。。。 有人有主意吗？我不知道我的调查方向是否错误。 非常感谢你的帮助

我在chroot中运行大量命令时遇到问题

有人有主意吗

命令行通常与环境变量和堆栈共享空间，无论您如何努力拉伸它们，仍然有一个限制

---

长期的解决办法是避免突破极限。例如，从make文件将

“humongous命令”

写入临时文件，而不是

sh-c“humongous命令”

，然后运行

sh/tmp/filename

。

我确实解决了在Makefile内部使用指向这些对象文件的基本路径的符号链接将指向对象文件的非常长的相对路径替换为较短版本的问题

@ln -s $(OBJ_BASE_PATH) ./a
NEW_OBJ_FILE_LIST=$(OLD_OBJ_FILE_LIST:$(OBJ_BASE_PATH)%=./a%)

之后，Makefile可以扩展$（NEW_OBJ_FILE_LIST），因为它足够短并且可以工作

---

我仍然很困惑，为什么在chroot之外它还能工作。我想唯一的原因可能是，在某种程度上，在chroot内部，系统正在将路径与chroot的基本路径“串联”，就像在我的例子中“/var/chroots/my_long_path_to_chroot/”一样，因此超过了限制。我没有投入任何额外的精力调查这一点，所以我不确认这一点，我只是假设。

重复？-我不知道这是否是，因为这可能与它在chroot内部失败有关，并且它有可能与之相关的感觉，因为它肯定有局限性，但我不知道是什么…问题是，无论以何种方式，如果您想通过命令与shell交互，Makefile必须扩展包含long命令的变量，因此它总是会失败。通过字符串连接构造这个长变量的选项将不是一个可行的选项，因为它意味着重写所有的makefile，而且在它构建的chroot之外没有任何意义。@Stan，在这种情况下，我没有解决方案。您可能在ServerFault上运气更好：这本身不是一个软件开发主题，而是管理主题。管理员更了解如何处理系统限制。