Anonymous | Login | Signup for a new account | 2025-01-14 14:23 CET |
My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0000509 | aMule | Misc | public | 2005-07-25 15:45 | 2008-07-02 11:33 | ||||
Reporter | afalout | ||||||||
Assigned To | |||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | open | ||||||
Platform | OS | OS Version | |||||||
Product Version | 2.0.3 | ||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0000509: error 24: Too many open files | ||||||||
Description | Downloading about 700 files, sharing 10000 Suse 9.3 x86_64 single Athlon CPU, 1 GB RAM Just few minutes after aMule starts, messages start appearing: aMule error: info: Could not create beckup of '<path>.404.part.met'(error 24: too many open files) Details show: * Impossible to get permission for file ... 404.part.met' (error 2: no such file or directory) * info: cound not create backup of ... * cant create file ....908.part.met.backup' (error 24: too manyu open files) *cant create file ...oart.met.bak (error 24: too many open files) * info: Could not create backup of .... .part.met ...etc... If I stop downloading about 100 files, messages stop. Noting that network connections apparently also count in open files (but they are counted in lsof below, which is signigicantly lower then my limits) Searched FAQ's, searched manual, Googled, not much usefull info. It does strike me as odd that most hits related to SuSE and ReiserFS (and since SuSE is the only distro using Reiser as default, it may as well be a Reiser related, but then I would expect that any production server running SuSE would be hittin this problem. Nothing on SuSE site (appart from standard 'increase /proc/sys/fs/file-max' Note that my aMule faithfully served for about a month untill this started. It started immediately after I added some 50 new files to downloads. Could it be a missleading message? Thank you for your help. | ||||||||
Additional Information | lsof reports programs with largest number of open files as: 115 master 124 amarokapp 129 y2base 132 firefox-b 140 smbd 147 firefox 214 kded 410 evolution 944 httpd2-pr 1084 amule Total open files: 6535 Kernel state: 4185 0 400000 (Max open files is set to 400000) See also possibly related issues: http://bugs.amule.org/view.php?id=73 [^] http://bugs.amule.org/view.php?id=204 [^] | ||||||||
Tags | No tags attached. | ||||||||
Fixed in Revision | |||||||||
Operating System | |||||||||
Attached Files | |||||||||
Notes | |
(0001172) Kry (manager) 2005-07-27 04:06 |
This is not a bug with aMule. Download less files, share less files (uploading them opens files), or increase the max open files on your linux system. |
(0001173) afalout (reporter) 2005-07-27 04:43 |
As mentioned, my file-max is set to 400000. Suse linux default is 203401 Four hundred thousand open files (handles) is not enough to download about 700 files, sharing 10000 (of which maybe 10 is open at any given time) ??? lsof dissagrees with this, and confirms that only 6535 files where open (including shockets) when aMule started reporting this error. Of those 6535 total, only 1084 file handles (includinfg shockets) where open by aMule itself. All this FACTS where stated in original report. Incientally; if ther is a limit of files to share or download with aMule, this should be clearly specified in a) documentation b) application itself - eg. aMule should issue a warning when user is trying to add more files to share/download then this limit you mentioned. Somehow, I am reasonably sure that aMule does not have built-in limits of this kind. But what do I know... Thanks Andrej |
Issue History | |||
Date Modified | Username | Field | Change |
2005-07-25 15:45 | afalout | New Issue | |
2005-07-27 04:06 | Kry | Note Added: 0001172 | |
2005-07-27 04:43 | afalout | Note Added: 0001173 | |
2008-07-02 11:33 | Wuischke | Status | new => closed |
Copyright © 2000 - 2025 MantisBT Team |