Hide Forgot
Description of problem: E.g. when building git-1.5.3.1 from the shipped SRPM, I get: + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot xargs: /usr/lib/rpm/check-rpaths-worker: Argument list too long error: Bad exit status from /var/tmp/rpm-tmp.31449 (%install) I get similar errors when I try to clean up my MH folders (delete all junk starting with ',', I've got some 11000 of those right now), in my $HOME: $ find Mail -name ',*' | xargs rm -f xargs: rm: Argument list too long Same annoyance when cleaning a kernel source for building, etc. Version-Release number of selected component (if applicable): findutils-4.2.31-2.fc8 How reproducible: Very often (makes it almost useless) Steps to Reproduce: Sorry, I seem not to be able to create a synthetic testcase where it fails. In any case, a "make clean" in a built kernel tree is a reliable way to trigger it here. Actual results: Expected results: Additional info:
*** Bug 366481 has been marked as a duplicate of this bug. ***
Still the same... on x86_64 this doesn't show. BTW, this is a dual-core i686. Strange thing is that this shows up all over the place, e.g. today when trying to build a new nmh RPM I got: + /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot xargs: /usr/lib/rpm/check-rpaths-worker: Argument list too long error: Bad exit status from /var/tmp/rpm-tmp.39544 (%install)
I just can't understand how you people can build new packages when /every/ package build fails here...
maybe it is, maybe it isn't, the solution to this bug, but if you are not trying to collect execve argument auditing with the audit system (auditctl -l shows nothing) feel free to up /proc/sys/kernel/audit_argv_kb. If this solves the problem a real solution will be in 2.6.25 kernel. that has nothing to do with the huge lists that you are seeing, maybe them being so big is a bug, maybe not, but at least this might help you get work done.
I haven't touched auditctl(8) at all, first time I hear about this... # auditctl -l LIST_RULES: exit,always syscall=chroot LIST_RULES: exit,always obj_type=dhclient_t (0xa) syscall=chdir LIST_RULES: exit,always obj_type=sendmail_t (0xa) syscall=chdir LIST_RULES: exit,always obj_type=mcstransd_t (0xb) syscall=chdir LIST_RULES: exit,always obj_type=sshd_t (0x6) syscall=chdir LIST_RULES: exit,always obj_type=ntpd_t (0x6) syscall=chdir LIST_RULES: exit,always obj_type=samba_t (0x7) syscall=chdir LIST_RULES: exit,always obj_type=named_t (0x7) syscall=chdir LIST_RULES: exit,always obj_type=klogd_t (0x7) syscall=chdir LIST_RULES: exit,always obj_type=crond_t (0x7) syscall=chdir LIST_RULES: exit,always obj_type=httpd_t (0x7) syscall=chdir LIST_RULES: exit,always obj_type=auditd_t (0x8) syscall=chdir LIST_RULES: exit,always obj_type=portmap_t (0x9) syscall=chdir LIST_RULES: exit,always obj_type=syslogd_t (0x9) syscall=chdir sysstat(rpm) is up, in any case. /proc/sys/kernel/audit_argv_kb is 32 (Is this that ARGV <= 32KiB?!). If so, there is something very wrong... isn't it supposed that xargs(1) (and its ilk) gets the maximal size of ARGV form the kernel? What would a reasonable value be here?
After "echo 128 > /proc/sys/kernel/audit_argv_kb" a "make clean" in the kernel goes through.
Hey, yeah, that solves my problems too. I had a directory containing ~5000 files, and had to move all those ending with 'png' to a new directory: mv *.png newdir : /bin/mv: Argument list too long. echo 128 > /proc/sys/kernel/audit_argv_kb mv *.png newdir : success! Who messed up the audit_argv_kb parameter? :-)
I'm not able to reproduce it, I think this is not problem anymore. Closing it. If I'm wrong, please reopen and update.