SUMMARY `balooctl` doesn't retain shell context (like `zypper`, `dnf`, or even `systemsettings`' CLI output does), instead merely printing over the shell prompt its output until another command is invoked. STEPS TO REPRODUCE 1. Install cpe:/o:opensuse:tumbleweed:20240321. 2. Install https://download.opensuse.org/repositories/openSUSE:/Factory/standard/x86_64/kf6-baloo-file-6.0.0-1.1.x86_64.rpm. 3. Invoke `balooctl enable` when it is disabled (via `balooctl disable`, for instance). OBSERVED RESULT It ends as expected, and the shell prompt is displayed. However, logs continue to be outputted to the shell (like the shell itself it has become it stdout, if that makes sense). EXPECTED RESULT It should retain the shell context so that its output isn't interrupted by the shell prompt, and so that it can be killed or *manually* `bg`'d by the user. SOFTWARE/OS VERSIONS Operating System: cpe:/o:opensuse:tumbleweed:20240321 KDE Plasma Version: 6.0.2 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.8.1-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor Memory: 30.5 GiB of RAM Graphics Processor: AMD Radeon RX 5700 Manufacturer: ASRock Product Name: X670E Taichi ADDITIONAL INFORMATION https://discuss.kde.org/t/balooctl-purge-fails-to-stop-baloo/12945/33?u=rokejulianlockhart
Its probably better if the daemon that `balooctl enable` starts just completely disconnects from the terminal. Compare for example with how Kate disconnects from the console when run from the command line.
(In reply to Oded Arbel from comment #1) I'd like to be able to see logs, if possible. Considering that it's a useful way to understand what it's doing without needing to debug it, as most except Kate's decisions to output them demonstrate. `bg` and KRunner provide the tools for pushing into a background process.
That sounds like debugging output (stderr) from the process started by balooctl, that comes asynchronously to the console if you start baloo_file with a "balooctl enable" and of course it's not listening to any of your controls. I eventually had success making ensure stderr goes to the journal, https://bugs.kde.org/show_bug.cgi?id=460390#c2. What's needed is that a "balooctl enable" does a "systemctl --user start kde-baloo" (rather than launch baloo_file itself)
(In reply to tagwerk19 from comment #3) Indeed, that was exactly why it didn't work for me - its systemctl service was disabled, so `balooctl enable` would merely fail, because it tried to bypass that.
Do you need this call still open?
(In reply to tagwerk19 from comment #5) > Do you need this call still open? Yes, this is still an issue. It actually worse than described, if you tend to use `balooctl disable` (or `balooctl6` on Plasma 6 - lets assume that from now on I use the correct `balooctl` command regardless of what I write). STEPS TO REPRODUCE: 1. Verify that under System Settings -> File Search, the indexer is enabled. 2. Verify that the baloo_file systemd service is active: `systemctl status --user kde-baloo.service` 3. Run `balooctl disable` to temporarily disable the indexer. 4. Verify that the baloo_file systemd service is inactive: `systemctl status --user kde-baloo.service` At this point if I try to reactivate the indexer, I can either: A. Run `balooctl enable` - all the service's debug logs will be output to the current terminal - making it unusable - while the systemd service is still inactive. B. Run `systemctl start --user kde-baloo.service` - this will fails with the error "Condition: start condition failed ... ExecCondition=/usr/bin/kde-systemd-start-condition --condition baloofilerc:Basic Settings:Indexing-Enabled:true" The only way to get it to start properly - i.e. running under the systemd service and not outputing logs to the console is like this: - `balooctl enable` - `killall baloo_file` - `systemctl start --user kde-baloo.service` I think the correct approach is for balooctl to detect that baloo_file should run under systemd and when doing "disable" - also stop the systemd service, then when doing "enable" - after setting the "Indexing-Enabled" condition, start the systemd service instead of running baloo_file attached to the terminal.
(In reply to Oded Arbel from comment #6) > ... I think the correct approach is for balooctl to detect that baloo_file > should run under systemd and when doing "disable" - also stop the systemd > service, then when doing "enable" - after setting the "Indexing-Enabled" > condition, start the systemd service instead of running baloo_file attached > to the terminal ... I agree and this would also mean that a manually restarted service would not escape the unit file memory limits. Cross referencing Bug 488178