Created attachment 157393 [details] Erroneous dialog SUMMARY baloo picks up changes of the config file, there is no need to restart the session. STEPS TO REPRODUCE 1. Open "File Search" 2. Change any setting 3. Click on "Apply" OBSERVED RESULT Inline dialog: "The system must be restarted before these changes will take effect. [Restart]". EXPECTED RESULT Update the config file. Done. SOFTWARE/OS VERSIONS Frameworks 5.104.0 Qt 5.18.8 ADDITIONAL INFORMATION
At the time this was added, worker processes that were already running did not pick up config changes (in particular, turning off Baloo entirely) and would need to be killed and restarted (or just killed, in the case where you turn off Baloo). To avoid exposing that technical detail to users, we found it easier to just recommend a reboot. Is that fixed now such that *all* config changes are picked up in real-time, and worker processes never need to be restarted before they notice said changes? Can you verify that?
The changes are picked up, eventually after a batch has been finished. Telling users "the system *must* be restarted" is just a lie. The changes are immediately picked up when the indexer is idle. Most of the changes will require some time until result are in the indexes, and restarting the system will only increase this delay. Turning baloo off is the one and only config change where implicitly killing the indexer due to a restart may have the intended effect, otherwise it just hurts.
Thanks. But can you think of a better way to explain all of that to the user in a friendly message that won't make their head spin? :) That's the challenge.
(In reply to Nate Graham from comment #3) > Thanks. But can you think of a better way to explain all of that to the user > in a friendly message that won't make their head spin? :) That's the > challenge. Wouldn't it make sense to do the equivalent of pkill baloo_file and relaunch it rather than rebooting the system? Anything "in progress" is lost in both cases but it would avoid a reboot ... which feels like, ouch, sorry for the pun, overkill.
Yes, that would probably work too. It's definitely better if we can react to changes in real-time.
I've tried out: systemctl --user restart kde-baloo and that seems to work. I'm not sure how KDE does/abstracts this for systems without systemd. It's not 100% though. If baloo has been started at logon, that seems to be fine - baloo_file is running as a service. In cases where baloo_file_extractor crashes and is rerun (by baloo_file), this still seems OK. The issue is where you do "balooctl purge", "balooctl disable" and "balooctl enable'. Here "baloo_file" does _not_ seem be running as a service. It would somehow be nice if this was consistent 8-)
Yeah, that would work for when using the systemd Plasma startup process, but that's optional and we can't guarantee it. So we would need fallback code to handle that, or else just display the old "restart your system now" UI for that use case.
The original analysis of the "bug" was wrong. The "misbehavior" of the indexer was actually a misinterpretation of the status line in the KCM.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1606
Git commit 7c946c26986f685ac9400dde83f714768611c0d8 by Stefan Brüns. Committed on 08/07/2023 at 14:12. Pushed by bruns into branch 'master'. Revert "kcms/baloo: prompt and warn users to reboot after changing settings" This reverts commit 4afb2b44bb816319c1d64dff1b6c2e7dbaeb3f63. Baloo already does pick up config changes at runtime, contrary to the statement of the original commit. The "bug" noticed by the reporter is just an artifact of the status/progress reporting. Claiming "Baloo needs a restart" when it does not puts Baloo in a bad light, and should be avoided. Related: bug 462009 M +0 -10 kcms/baloo/kcm.cpp M +0 -4 kcms/baloo/kcm.h M +0 -27 kcms/baloo/ui/main.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/7c946c26986f685ac9400dde83f714768611c0d8
(In reply to Stefan Brüns from comment #10) > Claiming "Baloo needs a restart" when it does not puts Baloo in a bad light, > and should be avoided. Agree, reverting is right. There were situations where baloo was "busy doing it own thing", not listening and not reponding. The one I've the most experience dealing with is solved here: https://invent.kde.org/frameworks/baloo/-/merge_requests/148 The pending change for BTRFS systems should also help https://invent.kde.org/frameworks/baloo/-/merge_requests/131 Fewer unneeded reindexings and smaller indexes. That would be a big step forward. We are left with the chance of a "stuck content indexer". There are going to be things you can throw at baloo that can take ages to index, gigabyte .mbox files for example or there was a PDF of a scientific plot that took a day to extract. Baloo_file seems not to hear "the signal" if it is waiting for baloo_file_extractor to finish (just double checked this on Neon Unstable with a folder of .mbox files)
(In reply to tagwerk19 from comment #11) > (In reply to Stefan Brüns from comment #10) > ... take ages to index, gigabyte .mbox files for example ... To extend this. The tests were running with systemd MemoryHigh=512M limit. It was lighter on the system but slowed down the content indexing substantially; a gigabyte .mbox file took about baloo_file_extractor about an hour compared to 3 minutes when unconstrained. Baloo seems not to respond during this content indexing.
Apologies, messed up the attributions... > ... take ages to index, gigabyte .mbox files for example ... was me, not Stefan.
(In reply to tagwerk19 from comment #11) > .... There were situations where baloo was "busy doing it own thing", not > listening and not responding .... Need to add in Bug 472493 here, if baloo is clearing out records for deleted files it seems not to respond.
*** Bug 483505 has been marked as a duplicate of this bug. ***