Similar to other users (see eg. 197206) I get these annoying "Failed to cleanly stop mldonkey" messages since net-p2p/mldonkey-2.9.3 . This would not be a big problem. But mldonkey also often produced corrupted files. With the corrupted download of the Gentoo 2008.0_beta1 (torrent) I started testing. I downloaded the 2008.0_beta2 amd64 version without any problem and without stopping mldonkey. While downloading the i686 version I stopped mldonkey (with the usual "Failed to cleanly stop mldonkey"). "file" tells me that the amd64 version is: "ISO 9660 CD-ROM filesystem data 'Gentoo Linux AMD64 LiveDVD ' (bootable)" while the i686 version is again "data". Reproducible: Always Steps to Reproduce: 1. Start a download in mldonkey 2. Stop mldonkey while downloading 3. Restart it and wait for the the download to finish (I did not try to reproduce it too often since it takes a while and mldonkey does not seem to "like" downloading a file twice even if the old one was corrupted and deleted) Actual Results: Download (all files) is corrupted data instead of anything usable. Expected Results: Like in the older versions of mldonkey I expect do be able to stop mldonkey (e.g. to shut down the machine) without risking data integrity of a download. I had corrupted download using net-p2p/mldonkey-2.9.3 and net-p2p/mldonkey-2.9.4. net-p2p/mldonkey-2.9.5 also produces the "Failed to cleanly stop mldonkey"-error message. The quoted message comes using baselayout2 but the problem also occurs using baselayout1.
By now I can confirm that also net-p2p/mldonkey-2.9.5 is corrupting mldonkey as well as BitTorrent downloads if shutdown during a download.
MLdonkey should never be forcefully killed by "kill -9" because it may not be able to write its ini files properly. Especially when downloading torrents it may happen that shutting down MLDonkey takes ~30s because the trackers have to be notified about stopping the download. When the init script has some kind of timeout for the shutdown of MLDonkey this will interfere with properly writing ini files back to disc.
(In reply to comment #2) > MLdonkey should never be forcefully killed by "kill -9" I am not killing it myself ... it is the /etc/init.d/mldonkey script itself. Your "kill -9" replacemant is the start-stop-daemon: start-stop-daemon --stop --exec "${MLDONKEY_BINARY}" \ --pidfile /var/run/"${SVCNAME}".pid > When the init script has some kind of timeout for the > shutdown of MLDonkey this will interfere with properly > writing ini files back to disc. What is your suggestion? Mabe changing MLDONKEY_TIMEOUT=${TIMEOUT:-20} to 90 seconds - should that be enough? If the solution is that simple the init.d script should be changed IMHO.
(In reply to comment #2) > Especially when downloading torrents it may happen that > shutting down MLDonkey takes ~30s because the trackers > have to be notified about stopping the download. I tried 90 and 900 seconds instead of 20 but mldonkey did not stop at all. In my opinion that is the main problem and not the "kill" in the init script.
> But mldonkey also often produced corrupted > files. With the corrupted download of the > Gentoo 2008.0_beta1 (torrent) I started testing. I never stop mldonkey using kill-9 but always use the proper script. If it doesn't work the first time (IT ALMOST NEVER DOES), I try once more (THIS USUALLY WORKS). From time to time I also get corrupted temporary files. I just delete all the *.tmp files from the mldonkey root directory, and everything works fine. If not, I try a backup from the old_config dir. I'm using mldonkey 2.9.6.. I wonder if it's a problem with the gentoo's supervisor, rather than with mldonkey itself. Still, I find it distasteful that a program doesn't terminate in few seconds when it's told.
Feel free to reopen if it still happens with a recent mldonkey version