Summary: | sys-devel/binutils-2.25.1-r1: patch 63_all_binutils-2.25.1-pt-pax-flags-20150727.patch fails "Too many open files" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | andj.scott |
Component: | Eclasses | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | CC: | gb_about_gnu |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch log |
Description
andj.scott
2016-04-02 21:05:13 UTC
What did you have the limit set to before increasing it? I hadn't set the limit before and removing those lines and returns the limit to 1024 according to 'sudo -u portage bash -c "ulimit -n"'. doubtful this is a bug in any particular ebuild i can't see how this is hardened related. i'm just guessing here, but if the bug is reproduceable, see what's in dmesg, if pax is killing something or grsec is presenting something because of a hard limit. not sure how we'd manage to hit a limit of even 1024 open fd normally running maybe portage team knows of a place to put some debug statements to try and capture the failing processes open limit (like /proc/<pid>/fd/). You can put something like this in /etc/portage/bashrc to log the open file descriptors an the beginning of src_prepare: pre_src_prepare() { elog "${FUNCNAME[0]}: max fd: $(ls -1 /proc/self/fd | tail -n1)" } That will tell us which direction to look in the process tree (open file descriptors that don't have the FD_CLOEXEC flag are typically inherited from parent processes to child processes). (In reply to Zac Medico from comment #6) > You can put something like this in /etc/portage/bashrc to log the open file > descriptors an the beginning of src_prepare: > > pre_src_prepare() { > elog "${FUNCNAME[0]}: max fd: $(ls -1 /proc/self/fd | tail -n1)" > } > > That will tell us which direction to look in the process tree (open file > descriptors that don't have the FD_CLOEXEC flag are typically inherited from > parent processes to child processes). Actually better use wc -l like this: pre_src_prepare() { elog "${FUNCNAME[0]}: fd count: $(ls -1 /proc/self/fd | wc -l)" } *** Bug 593092 has been marked as a duplicate of this bug. *** I can acknowledge that this bug is not related to hardended, because I encountered it on non-hardened amd64-system (using the new x32 ABI) too. See (duplicate) bug 593092 for additional material, such as a directory listing of the working directory after the error message had been displayed. Now I wonder whether "patch" could perhaps be so stupid to open all the files mentioned in the patch at once, keeping them open until all patch chunks have been applied, and only after that close them. This would mean the "number of open files"-limit needed to be at least as large as the number of files affected by the patch. On the other hand, are there even 1024 files in the whole binutils source package? 1024 is actually a rather large count of source files. binutils is not the Linux kernel or LibreOffice, which certainly contain more files. I also severely doubt that the authors of "patch" could really have implemented this utility in such an inefficient way. It seems "patch" is really that braindead! I just straced the "patch" invocation from bug 593092 and saved the strace output as file "out". Then: $ grep ^close out | wc -l 115 $ grep ^open out | wc -l 1139 It seems, the open file limit actually reached 1024, so it is not a bug in the ebuild infrastructure, in the sandbox, or generally anywhere in the build system. "patch" seems to require a number of open filehandles which is at least partially proportional to the number of files affected by the patch. So the real questions here are: * How to increment the resource limit for the ebuild process, avoiding this problem. * Why does not everyone who tries to emerge this package encounter the same problem. Regarding the last point, I have a suspicion: I am running a completely "systemd"-free system with no logind, consolekit or any other "Poettering" service running. I have also globally disabled the "pam" USE flag, because I hate the increased configuration complexity which comes with PAM. Perhaps most other people *do* use some of those things, and some of them interact with the resource limits and boost them, giving those people higher limits. I have no idea how I can raise the resource limits for the "portage" user right now, but I will see into it. It would be interesting whether other people who encountered the "too many files" issue have PAM and/or Poettering services disabled, too. Which version of sys-devel/patch was this? (In reply to Andreas K. Hüttel from comment #11) > Which version of sys-devel/patch was this? I am sorry, I can't tell any more. I stopped using Gentoo a year or so ago, when I encountered combined version+USE-flag dependency hell after making the grave mistake to skip updating for a couple of months. I am using Devuan now, and my original Gentoo installation does not exist any more. But try this: Apply some large patch affecting many files like this: $ strace -f patch -p1 < some.patch 2> plog Then grep + wc the plog file and see whether the open() and close() syscall counts are similar, which has to be expected if they are paired/balanced. But if you see a lot more open than close calls, then you are using a version of patch which obviously has the same problem as mine did. (In reply to Guenther Brunthaler from comment #12) > (In reply to Andreas K. Hüttel from comment #11) > > Which version of sys-devel/patch was this? > > I am sorry, I can't tell any more. > > I stopped using Gentoo a year or so ago, when I encountered combined > version+USE-flag dependency hell after making the grave mistake to skip > updating for a couple of months. > > I am using Devuan now, and my original Gentoo installation does not exist > any more. > > But try this: Apply some large patch affecting many files like this: > > $ strace -f patch -p1 < some.patch 2> plog > > Then grep + wc the plog file and see whether the open() and close() syscall > counts are similar, which has to be expected if they are paired/balanced. > > But if you see a lot more open than close calls, then you are using a > version of patch which obviously has the same problem as mine did. OK |