It seems that KTorrent is filling up the .xsession-errors log with every connection it makes. Here's an example of the of the output: tor. sep. 1 20:06:56 2016: Accepted connection from 50.65.xx.xx tor. sep. 1 20:06:56 2016: Accepted connection from 81.224.xx.xx tor. sep. 1 20:06:57 2016: Authentication(S) to 50.65.xx.xx : ok tor. sep. 1 20:06:57 2016: Authentication(S) to 81.224.xx.xx : ok tor. sep. 1 20:06:57 2016: Accepted connection from 188.142.xx.xx tor. sep. 1 20:06:57 2016: Accepted connection from 222.97.xx.xx tor. sep. 1 20:06:57 2016: Authentication(S) to 188.142.219.54 : ok tor. sep. 1 20:06:57 2016: Authentication(S) to 222.97.167.160 : failure tor. sep. 1 20:06:58 2016: Accepted connection from 185.148.xx.xx tor. sep. 1 20:06:58 2016: Authentication(S) to 185.148.xx.xx : failure As you can see, they come quite frequently and after 2 and half days of uptime the log is now 230 MB. The client is running with 32 torrents seeding. When I quite ktorrent the messages stop, and they begin again when ktorrent is restarted. Reproducible: Always Steps to Reproduce: 1. Start ktorrent with some torrents running 2. tail -f .xsession-errors Actual Results: KTorrent logs every connection (it seems) Expected Results: Ktorrent should not fill up the .xsession-errors that fast. I'm running the arch linux package of ktorrent, version 5.0.1-2. kio version 5.25.0-1.
Yes, this is happening here, too, with KTorrent 5. A flood of messages is printed to stdout, and I have to work around it for now by setting up a custom desktop file to run ktorrent with stdout redirected to /dev/null. After a bunch of digging, it looks like this is set in the libktorrent code, in util/log.h at line 97: void setOutputToConsole(bool on); The comments say: * By default all messages will also be printed on the standard output. This * can be turned down using the @a setOutputToConsole function. I don't know all the reasons that default may have been chosen... From my experience, I'd be delighted if the default for general distribution was changed to 'off'. :) If not, is it a matter of where the log level is chosen, somewhere else, and the problem is that we're getting all these LOG_NOTICE and some LOG_DEBUG messages? This is echoing what Knut said, but here's the impact this is having: Over several days of running ktorrent off and on, my .xsession-errors file has grown to over a gigabyte. The vast majority of that file is ktorrent's messages. I first noticed this problem when trying to find another program's diagnostics in .xsession-errors; it becomes a bit of a DOS attack against trying to find anything in that file. :) I haven't done a performance analysis, but from past experiences, I would think the heavy logging would have at least some performance impact? Thank you, if you'll consider this. And thank you for KTorrent! (I'm running the Fedora rawhide package of ktorrent 5.0.1, under fedora 25. I got the package from https://rpmfind.net/linux/RPM/fedora/devel/rawhide/x86_64/k/ktorrent-5.0.1-3.fc26.x86_64.html )
Git commit af1abedb3bc5cd8e73f134e123857b0f9dcaa239 by Valeriy Malov. Committed on 14/12/2017 at 12:44. Pushed by valeriymalov into branch 'master'. Disable logging to stdout by default Summary: Do not log to stdout by default since ktorrent logs are very verbose and pollute session log (e.g. xsession-errors), while ktorrent manages it's own log files in ~/.local/share/ktorrent. Add command line option to enable logging to stadnard output again, if needed. Remove some duplicate headers. Reviewers: stikonas Subscribers: ltoscano Differential Revision: https://phabricator.kde.org/D8438 M +3 -5 ktorrent/main.cpp https://commits.kde.org/ktorrent/af1abedb3bc5cd8e73f134e123857b0f9dcaa239
Don't ask me how but somehow 5.1 branch does NOT have the fix: https://cgit.kde.org/ktorrent.git/tree/ktorrent/main.cpp?h=5.1#n211 Master does have the fix: https://cgit.kde.org/ktorrent.git/tree/ktorrent/main.cpp#n206 I'm guessing a mistake was made during merge at some point. Consider cherry picking af1abedb3bc5cd8e73f134e123857b0f9dcaa239 into 5.1 branch.
*** Bug 411152 has been marked as a duplicate of this bug. ***
Setting this as fixed again since 5.1 is a few years old