[Mldonkey-bugs] [bugs #10770] No response from core (when too many sources are available?)

[anonymous]

This mail is an automated notification from the bugs tracker
 of the project: mldonkey, a multi-networks file-sharing client.

/**************************************************************************/
[bugs #10770] Latest Modifications:

Changes by: Anonymous user
Date:  
                lun 15.11.2004 at 08:41

------------------ Additional Follow-up Comments ----------------------------
I have had the same problem for a long time, and ulimit is not a solution (it's 
"unlimited" on my platform - mac os x). But I've investigated the problem a bit 
further and found 3 linked phenomenons :
- the mlnet process takes more and more cpu time (until I have 0% idle using 
top)
- the interface (html or telnet) becomes less and less responsive (and 
eventually ends up not responding at all)
- and MOST IMPORANT : the number of "dead" connections constantly grows (i can 
see that using netstat, fstat, or lsof)

My workaround, until now, has been to write a "mldonkey_watch" shell script 
which monitors the daemon's behaviour based on 2 criterias :
- number of dead connections - I decide to restart the core when it reaches 200
- reactivity of the core to commands via telnet (actually netcat) - I consider 
mlnet is hung when it doesn't respond for one minute
- I didn't figure out yet how to monitor cpu usage (which I think is a side 
effect)

Then I send a "kill" command to mlnet, wait one more minute, and if it was 
ineffective, kill the process the unix way.

I have to add that this misbehaviour of mldonkey (I'm only using the edonkey 
protocol) used to cause kernel panics in my system (which were located in the 
driver of my pci - dsl modem). And since I have mldonket monitored, my system 
has regained an impressive stability !

I nevertheless think this issue should better be fixed...






/**************************************************************************/
[bugs #10770] Full Item Snapshot:

URL: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=10770>
Project: mldonkey, a multi-networks file-sharing client
Submitted by: PJ CLEMENCEAU
On: ven 22.10.2004 at 14:58

Category:  Core
Severity:  5 - Average
Item Group:  Program malfunction
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open
Release:  2-5-16
Release:  2-5-16
Platform Version:  Mac OS X Jaguar
Binaries Origin:  CVS / Self compiled
CPU type:  PowerPC


Summary:  No response from core (when too many sources are available?)

Original Submission:  After a few hours (2 or 3), I get no response from the 
core when using the html or telnet interface.
This happens since I have been trying to dl a file that has numerous sources 
(>4000), and also for which I get more than 100 ul requests.

A hinch may come from the following message, that I get when trying to access 
options page, and usually this message appears shortly before "failure". 
Message is : "Exception opendir failedon ./html_themes: Too many open files"


Follow-up Comments
------------------


-------------------------------------------------------
Date: lun 15.11.2004 at 08:41       By: 0 <None>
I have had the same problem for a long time, and ulimit is not a solution (it's 
"unlimited" on my platform - mac os x). But I've investigated the problem a bit 
further and found 3 linked phenomenons :
- the mlnet process takes more and more cpu time (until I have 0% idle using 
top)
- the interface (html or telnet) becomes less and less responsive (and 
eventually ends up not responding at all)
- and MOST IMPORANT : the number of "dead" connections constantly grows (i can 
see that using netstat, fstat, or lsof)

My workaround, until now, has been to write a "mldonkey_watch" shell script 
which monitors the daemon's behaviour based on 2 criterias :
- number of dead connections - I decide to restart the core when it reaches 200
- reactivity of the core to commands via telnet (actually netcat) - I consider 
mlnet is hung when it doesn't respond for one minute
- I didn't figure out yet how to monitor cpu usage (which I think is a side 
effect)

Then I send a "kill" command to mlnet, wait one more minute, and if it was 
ineffective, kill the process the unix way.

I have to add that this misbehaviour of mldonkey (I'm only using the edonkey 
protocol) used to cause kernel panics in my system (which were located in the 
driver of my pci - dsl modem). And since I have mldonket monitored, my system 
has regained an impressive stability !

I nevertheless think this issue should better be fixed...

-------------------------------------------------------
Date: dim 24.10.2004 at 15:21       By: PJ CLEMENCEAU <pjc>
I have tried using ulimit. Doesn't help.
The only item I have currently perform that seems to help (but still end up in 
the end with no response) is to limit the number of servers to 2 and suppress 
auto-refresh of servers list. It actually limits a little the number of 
available sources, thus giving more time....

PS : one other point : altough the web interface fails, the telnet interface, 
if launched from the start, continues to work. 
This gives me the following results : when core "stops" responding, actually 
some downloads continue for some time, then slowly drop out, and then no new 
download come in, the core just sits "waiting". If I kill it and relaunch it, 
it automatically finds new sources and will perform new downloads... and in the 
end once again stop responding.


-------------------------------------------------------
Date: sam 23.10.2004 at 11:25       By: Hansi Husten <HansiHusten>
100% agreed, also in -28h with BT

-------------------------------------------------------
Date: ven 22.10.2004 at 18:25       By: spiralvoice <spiralvoice>
Try raising limits for mlnet using ulimit












For detailed info, follow this link:
<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=10770>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/