| Summary: | balooctl prints output over shell, and doesn't accept control codes from user. | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | Roke Julian Lockhart Beedell <4wy78uwh> |
| Component: | balooctl | Assignee: | baloo-bugs-null |
| Status: | REPORTED --- | ||
| Severity: | minor | CC: | oded, tagwerk19 |
| Priority: | NOR | Flags: | 4wy78uwh:
performance-
|
| Version: | 5.115.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| URL: | https://discuss.kde.org/t/balooctl-purge-fails-to-stop-baloo/12945/33?u=rokejulianlockhart | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=488178 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Roke Julian Lockhart Beedell
2024-03-25 18:21:13 UTC
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 |