Community
Participate
Working Groups
I've not seen this before, and have not confirmed reproducible, but since potentially bad, thought I'd enter what I know. I was testing Indigo RC4 Java EE IDE shared installed scenarios. Installed Java EE into /usr/local/... Installed a few extra things, PHP, etc., then went to to the matching "webtools site" which, since not released yet is http://download.eclipse.org/webtools/downloads/drops/R3.3.0/S-3.3.0RC4b-20110607160810/repository/ I selected all the matching "SDK" features from webtools site (the use case is to get the source bundles, for webtools features already installed). After a bit, received "failed" dialog with following message. An error occurred during the org.eclipse.equinox.internal.p2.engine.phases.CheckTrust phase. session context was:(profile=epp.package.jee, phase=org.eclipse.equinox.internal.p2.engine.phases.CheckTrust, operand=, action=). Error reading signed content. /home/davidw/.eclipse/org.eclipse.platform_3.7.0_692754952/features/org.eclipse.wst.web_sdk.feature_3.3.0.v201102200555-7E7E-8Sxdj463QDoxz0DUJeVYV-mU9eq1IIQIA9w/META-INF/ECLIPSEF.SF (Too many open files) Maybe I really am overloading my little ubuntu system and need to increment "file handles". From ulimit -n my default appears to be 1024 ... but ... seems a little odd I'd have to ... especially given that I haven't seen before.
I doubt that this is a package specific problem. I've had similar issues in the past years when building the huge modeling package on the server. At that time I introduced a ulimit -n 2048 in my build script. This solved it in the p2 director call, but it is not a solution that I would suggest to end users.
I did try just restarting, and reinstalling those sdk features, and it completed in like 1 second ... like it had everything cached, ready to go ... and did not hit the "too many files open" problem. So, I'd say this is at least not blocking :/ I'll try to investigate systematically later and see if I can find a reproducible scenarios that could be used to see if someone is forgetting to close files. (Thanks Markus ... unfortunately, on my Ubuntu system ... I need to first figure out how to set the hard limit higher! araaugh)
(In reply to comment #2) > (Thanks Markus ... unfortunately, on my Ubuntu system ... I need to first > figure out how to set the hard limit higher! araaugh) It could be compiled into the kernel as a hard limit for every process, I remember a header file called ulimit.h. AFAIK this is one difference between the 'Ubuntu' and the 'Ubuntu Server' edition. I am pretty sure you can install the server kernel with one of the apt/aptitude/apt-get/... tools.
(In reply to comment #3) > (In reply to comment #2) > > (Thanks Markus ... unfortunately, on my Ubuntu system ... I need to first > > figure out how to set the hard limit higher! araaugh) > > It could be compiled into the kernel as a hard limit for every process, I > remember a header file called ulimit.h. AFAIK this is one difference between > the 'Ubuntu' and the 'Ubuntu Server' edition. I am pretty sure you can install > the server kernel with one of the apt/aptitude/apt-get/... tools. no need to recompile kernel! :) ... there's a file (at least, in Ubuntu 10.10 (or, actually, Linux Mint 10 is what I'm using), /etc/security/limits.conf, where per user limits can be increased. The frustrating part (the "araaugh" part), was because I had to reboot for it to take effect ... pretty rare in Linux.
Appears this has happened before ... will dup as 300589 because it too mentions happening during signing check, but see also bug 302044. I've tried several time to recreate by "installing lots of stuff" and have not hit the error about file handles again so ... perhaps interacts with the state of the mirroring system, or something (such as, just guessing, hitting a bad mirror leaves a file open, or similar). I did hit a potentially bad error in one case where I could not restart my eclipse, but it did not mention "too many files open" so could be something else. See bug 349105. *** This bug has been marked as a duplicate of bug 300589 ***