Bug 368877 - log_kio_sftp log flood
Summary: log_kio_sftp log flood
Status: RESOLVED FIXED
Alias: None
Product: kio-extras
Classification: Frameworks and Libraries
Component: SFTP (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Andreas Schneider
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-16 02:12 UTC by David Shen
Modified: 2018-10-24 14:13 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 18.12.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Shen 2016-09-16 02:12:28 UTC
When copying files from a remote location to local through sfftp, I saw kdeinit is loggin "log_kio_sftp" like crazy.

kdeinit5[838]: log_kio_sftp: enqueueChunks
kdeinit5[838]: log_kio_sftp: enqueueChunks done "1"
kdeinit5[838]: log_kio_sftp: enqueueChunks
kdeinit5[838]: log_kio_sftp: enqueueChunks done "1"
kdeinit5[838]: log_kio_sftp: enqueueChunks
kdeinit5[838]: log_kio_sftp: enqueueChunks done "1"


I have tons of logs in my journalist. I wonder if it is necessary, or may be something is wrong.

I created the sftp connection through the Dolphin GUI.


Reproducible: Always

Steps to Reproduce:
1. Create a connection to a SFTP location
2. Copy a large file from the remote to local
3. Observer log with "journalctl -f"

Actual Results:  
log_kio_sftp log floods

Expected Results:  
Some info. log about kio status
Comment 1 David Shen 2018-09-03 13:56:16 UTC
I just tried on my system which has kio-5.46.0 and kio-extras-18.04.3 installed, and this issue persists.
Comment 2 Andreas Schneider 2018-09-03 15:14:10 UTC
I've removed the messages in my WIP branch.
Comment 3 Nate Graham 2018-09-03 15:42:07 UTC
Thanks for working on this, Andreas! Can we see the work-in-progress anywhere?
Comment 4 Andreas Schneider 2018-09-03 17:41:42 UTC
Nate, you can find it here:

https://gitlab.com/cryptomilk/kio-extras/commits/asn/master-sftp
Comment 5 Nate Graham 2018-09-03 21:32:19 UTC
Thanks Andreas!

Experience shows that submitting a patch consisting of giant changeset from a whole branch worth of work is very difficult to adequately review, and unfortunately it may get buried over time and abandoned. Is there any chance you could start to submit small targeted patches for one issue at a time so that we can review them independently of one another? I see you already have a number of commits on that branch; you could just submit each one (or each group of related ones) as a separate patch. Let me know if you need a hand with anything.
Comment 6 Andreas Schneider 2018-09-04 07:34:08 UTC
Hi Nate,

I don't really understand what you mean exactly. The individual patches are as small as possible and easy to review as the only address one issue at the time.

Do you want that I create a branch for each bug which gets addressed?

That's the only thing which would make sense to further split them up.
Comment 7 Nate Graham 2018-09-05 03:40:01 UTC
Yeah, the ideal workflow from a KDE perspective is to submit one patch per bug report. Each patch should have its own branch. I guess since you already have a development branch, you could cherry-pick the appropriate commits onto the patch branches that you submit using Phabricator.

Basically all I want to warn you about is that if you submit your entire branch as a single patch, experience indicates that the full changeset may be too overwhelming to get a proper review.
Comment 8 Andreas Schneider 2018-09-05 06:03:10 UTC
Nate, I'm aware of that ;-)

FYI:

grep arcdiff .gitconfig 
        arcdiff = rebase -i --exec 'arc diff HEAD^'
Comment 9 Nate Graham 2018-09-05 18:42:36 UTC
All right, great. Looking forward to the patches!
Comment 10 Andreas Schneider 2018-09-05 20:28:54 UTC
First I need to release libssh 0.8.3, but we don't have all patches done for it yet. Hopefully next week.
Comment 11 Harald Sitter 2018-10-23 14:22:35 UTC
I am almost entirely certain that this was fixed by https://commits.kde.org/kio-extras/44e800dc1c15a374168b262a87ff4da3a57d1772 (targeting 18.12) which changed the default logging level from debug to info.
The original debug header set no category which uses the default of everything-enabled. The new auto generated header explicitly sets the default category to info. This means all debug calls are no-op now; that includes the enqueueChunks messages.

http://doc.qt.io/qt-5/qloggingcategory.html#Q_LOGGING_CATEGORY
http://doc.qt.io/qt-5/qloggingcategory.html#Q_LOGGING_CATEGORY-1
Comment 12 Harald Sitter 2018-10-24 14:13:52 UTC
Git commit bf4563e8d291477a8cca0e632561498f47e4672a by Harald Sitter.
Committed on 24/10/2018 at 14:13.
Pushed by sitter into branch 'master'.

[sftp] put request chunk debugging into own category

Summary:
it's excessively verbose and not necessarily useful unless one is actually
debugging request handling, so separating this from the general slave
debugging seems handy as one can enable one without the other.

Test Plan: builds, installs, has separate logging categories

Reviewers: asn, broulik, ngraham

Reviewed By: broulik

Subscribers: kde-frameworks-devel, kfm-devel

Tags: #dolphin, #frameworks

Differential Revision: https://phabricator.kde.org/D16387

M  +5    -0    sftp/CMakeLists.txt
M  +3    -2    sftp/kio_sftp.cpp

https://commits.kde.org/kio-extras/bf4563e8d291477a8cca0e632561498f47e4672a