| Summary: | Wishlist: Baloo debugging | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | tagwerk19 |
| Component: | general | Assignee: | baloo-bugs-null |
| Status: | REPORTED --- | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | 5.99.0 | ||
| Target Milestone: | --- | ||
| Platform: | Neon | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
(In reply to tagwerk19 from comment #0) > It should be that messages also get logged (journald?) but I don't seem to be > able to enable these. Some messages are logged but the bulk appear only > on the terminal. There's something wierd here. I would expect if I have a qtlogging.ini file I could follow debug messages with journalctl -f I see a couple of messages after I run balooctl purge and that's it; the majority of the messages appear (only) on the terminal. I see that there are a number of QT environment variables that are supposed to switch logging to or from the terminal but I've not found a recipe that works... I have stumbled on a hack that *does* redirect debugging to journald but it just makes the issue more confusing: balooctl purge 2> stderr.log works in that it gives you reindexing messages in the journal, not on the screen (and not to the stderr.log file). What could be happening here? As per:
https://www.freedesktop.org/software/systemd/man/systemd.exec.html#StandardOutput=
add a
StandardError=journal
to the unit file.
This can be done with
systemctl edit --user kde-baloo.service
adding
[Service]
StandardError=journal
and saving the override.
This seems to make the logging more predictable.
|
SUMMARY: It should be possible to run baloo with debugging and follow the what the code is doing. At the moment there it little debugging available, an issue referenced in: https://bugs.kde.org/show_bug.cgi?id=457522#c24 STEPS TO REPRODUCE: Enable debugging by creating a: ~/.config/QtProject/qtlogging.ini containing: [rules] kf.*.debug=true as per: https://doc.qt.io/qt-5/qloggingcategory.html#logging-rules https://community.kde.org/Guidelines_and_HOWTOs/Debugging/Using_Error_Messages After this run baloo/balooctl from the command line (where possible) and watch log messages sent to the terminal. It should be that messages also get logged (journald?) but I don't seem to be able to enable these. Some messages are logged but the bulk appear only on the terminal. USE CASES: I've included some cases below where extra debugging would help sort out existing issues. In Bug 368557: Need enough debugging to track back and find out when and why baloo stops reacting to inotify messages. This happens, sometimes when an indexed folder is renamed (https://bugs.kde.org/show_bug.cgi?id=392793#c3) but also other times where it's not possible to identify the trigger (Bug 368557) This would need the stream of debug messages to appear in syslog/journald. In Bug 459572: Make the behaviour as/when baloo meets a symbolic link easier to follow, in particular when searching from folders (that might be indexed or not). It's not easy to guess what is happening in a case such as Bug 459572, at the moment this requires some guesswork. In Bug 457522: Following the issues listed in: https://bugs.kde.org/show_bug.cgi?id=457522#c17 Need something to show why baloo decides on different mimetypes for the "test.m" file when it does (or doesn't do) content indexing. SOFTWARE/OS VERSIONS Neon Unstable Plasma: 5.26.80 Frameworks: 5.100.0 Qt: 5.15.6 ADDITIONAL INFORMATION In broader terms there should be enough debugging available to follow what baloo was doing and make it less of a "Black Box, Behaving Strangely". These are a few suggestions: With: balooctl index test.txt it should be possible to follow the process of parsing the command, determining the mime type, extracting the terms and that the data is committed through lmdb. Then, in a test environment with one file in a single indexed folder, with a: balooctl purge it should be possible to see the database being deleted, follow the folders being scanned, inotify watches registered and the files to be index identified - then the indexing of the individual file(s) as above. It should be possible to follow the process when a file is renamed or deleted - showing the inotify messages and subsequent updates to the database. When searching it should be possible to follow the baloosearch logic when, for example, parsing the arguments in something like: baloosearch test AND one OR two and similarly when searching via krunner: krunner test should show how krunner queries baloo, weaves its results together and categorises them. It's clear that this has to be a slow, incremental process, deciding on extra logging categories (as potentially there might be a lot of trace output) and gradually adding conditional debug statements.