Внутри chroot execvp() возвращает слишком длинный список аргументов

У меня проблема с массивной командой внутри chroot. Сама команда инициируется Makefile поэтому ошибка является классическим:Внутри chroot execvp() возвращает слишком длинный список аргументов

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

Я расследование, и я понял, глядя на исходный код сделать, что он создает работу через execvp(), который предоставляется LIBC (I» мы видели, что команда передается как «/ 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. Однако такой же результат ... У кого-нибудь есть идея? Я не знаю, изучаю ли я неправильное направление или нет. Большое спасибо за любую помощь!

источник

2016-06-21 Stan

Duplicate? - http://unix.stackexchange.com/questions/120642/what-defines-the-maximum-size-for-a-command-single-argument – Dummy00001

Я не знаю, так ли это, поскольку это может быть связано с тот факт, что он терпит неудачу внутри chroot, и у него есть чувство, что это может быть связано с ним, так как есть определенные ограничения с ним, но я не знаю, что ... – Stan

У меня проблема с массивной командой внутри chroot.

У кого-нибудь есть идеи?

Командная строка обычно разделяет пространство с переменными окружения и стекю, и как бы вы ни старались их растянуть, существует еще предел.

Долгосрочное решение заключается в том, чтобы не нажимать на пределы. Например, вместо sh -c "humongous command" из файла make напишите "humongous command" во временный файл и вместо этого запустите sh /tmp/filename.

источник

2016-06-22 10:15:36 Dummy00001

Вам не нужен файл; 'printf 'humongous command \ n' | sh' – tripleee

Проблема заключается в том, что каким-либо образом вы хотите взаимодействовать с оболочкой через команду Makefile, чтобы расширить переменную, которая содержит длинную команду, поэтому она всегда будет терпеть неудачу. Вариант построения этой длинной переменной посредством конкатенации строк не был бы жизнеспособным вариантом, поскольку это означало бы переписать все Make-файлы, и это не будет иметь никакого смысла, поскольку вне chroot он строит отлично. – Stan

@Stan, в этом случае у меня нет решения для вас.Возможно, вам лучше повезло с ServerFault: это не само по себе тема разработки программного обеспечения, а администрирование. Админы лучше знают, как работать с системными ограничениями. – Dummy00001

Я решил проблему, заменяющую в 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_the_chroot/и, следовательно, с превышением предела. Я не прикладываю никаких дополнительных усилий, чтобы расследовать это, поэтому я не подтверждаю это, я просто предполагаю.

источник

2016-06-23 12:49:14 Stan

Внутри chroot execvp() возвращает слишком длинный список аргументов

ответ

Смежные вопросы