Summary: | baloo_file doesn't start when desktop plasma starts | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-baloo | Reporter: | skierpage <skierpage> |
Component: | general | Assignee: | baloo-bugs-null |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | nate, rdieter, scott.beamer, tagwerk19 |
Priority: | NOR | ||
Version: | 5.83.0 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/plasma/plasma-workspace/-/commit/ed4b92af374f7072b618e59b2dc4172ea359d4be | Version Fixed In: | 5.22.4 |
Attachments: | diff of service generated from xdg file and kde-baloo.service |
Description
skierpage
2021-06-30 19:11:58 UTC
Suspect this could be related: https://bugzilla.redhat.com/show_bug.cgi?id=1951580 https://github.com/systemd/systemd/issues/18791 "xdg-autostart-generator: unconditionally ignores items with X-GNOME-Autostart-Phase" I have trouble with an upgraded F34 in a VM not running the spice-vdagent; a clean install F34 works. ... I'm guessing .config/baloofilerc I notice in the /etc/xdg/autostart/baloo_file.desktop file there is a line X-systemd-skip=true Doesn't seem to bother Neon but maybe Neon "relies less" on systemd. This is somehow a regression (as there wasn't an issue F33). If I remove the X-systemd-skip line, baloo starts up OK. It may be worth though watching the desktop file to see whether updates re-add the line. (In reply to tagwerk19 from comment #2) Many thanks for your suggestions! > If I remove the X-systemd-skip line, baloo starts up OK. If I comment out both X-GNOME-Autostart-enabled=true and X-systemd-skip=true in /etc/xdg/autostart/baloo_file.desktop , then running /usr/lib/systemd/user-generators/systemd-xdg-autostart-generator creates a /tmp/app-baloo_file@autostart.service So maybe these changes will get baloo_file to run after my next reboot. (I couldn't figure out how to get the `log_warning_errno()` lines in systemd-xdg-autostart-generator to log, `sudo systemd-analyze set-log-level 7` didn't do it.) The Fedora 34 kde-baloo package already provides a /usr/lib/systemd/user/kde-baloo.service file, so I'm confused why systemd-xdg-autostart-generator needs to create another service file. (In reply to skierpage from comment #3) > (In reply to tagwerk19 from comment #2) > Many thanks for your suggestions! > > > If I remove the X-systemd-skip line, baloo starts up OK. I commented out both > X-GNOME-Autostart-enabled=true > and > X-systemd-skip=true > in /etc/xdg/autostart/baloo_file.desktop , ... and on next reboot baloo_file started up fine! The actual service unit running is not kde-baloo.service, but % systemctl --user status app-baloo_file@autostart.service ● app-baloo_file@autostart.service - Baloo File Daemon Loaded: loaded (/etc/xdg/autostart/baloo_file.desktop; generated) Active: active (running) since Sat 2021-07-10 15:35:41 PDT; 7h ago (In reply to tagwerk19 from comment #2) > This is somehow a regression (as there wasn't an issue F33). If I remove the > X-systemd-skip line, baloo starts up OK. Yes I think that's it, so I was probably wrong to mention this baloo_file issue in systemd issue 18791. KDE commit 048edc5d2b29ea77d4e4226528e42031aac1c59a added the X-systemd-skip=true line: > Author: Henri Chain <henri.chain@enioka.com> > Date: Thu Oct 15 09:21:09 2020 +0200 > Fix baloo_file autostart with systemd > Makes baloo_file started by systemd when systemd boot is enabled. > Disables auto generation of a service file by recent systemd > Will need to add `Wants=kde-baloo.service` to `plasma-workspace@.target` But this last bit is not in plasma-workspace.git's startkde/systemd/plasma-workspace@.target file, yet, so I tried it. I reverted to the original /etc/xdg/autostart/baloo_file.desktop and made the suggested change to /usr/lib/systemd/user/plasma-workspace@.target and rebooted, and kde-baloo.service started fine 👍. The previously generated /run/user/1000/systemd/generator.late/app-baloo_file@autostart.service is different from /usr/lib/systemd/user/kde-baloo.service (see attachment), the former has different settings, e.g. Restart=no, a different Slice name, and the extra ExecCondition=/usr/lib/systemd/systemd-xdg-autostart-condition "KDE:GNOME:Unity:XFCE" "" I'm no expert in grokking systemctl trees to tell if these are significant and belong in /usr/lib/systemd/user/kde-baloo.service. Created attachment 140001 [details] diff of service generated from xdg file and kde-baloo.service The /run/user/1000/systemd/generator.late/app-baloo_file@autostart.service file that systemd-xdg-autostart-generator generates from /etc/xdg/autostart/baloo_file.desktop is different from the kde-baloo.service file provided by baloo. I'm not sure if the differences are significant. Fixed by you with https://invent.kde.org/plasma/plasma-workspace/-/commit/ed4b92af374f7072b618e59b2dc4172ea359d4be in Plasma 5.23! Chapeau! ... If baloo can be run via systemd, does this open the possibility of using systemd cgroup settings to cap memory use? (Yes, thread drift, sorry...) (In reply to tagwerk19 from comment #8) > ... If baloo can be run via systemd, does this open the possibility of using > systemd cgroup settings to cap memory use? (Yes, thread drift, sorry...) In Fedora 34, baloo is run by systemd before and after this fix. I mentioned in comment 6 that the service files are different, putting baloo_file in different slices that as I understand it may have different resource limits. Yes, kde-baloo.service could have more settings. (In reply to tagwerk19 from comment #1) > Suspect this could be related: > https://bugzilla.redhat.com/show_bug.cgi?id=1951580 > https://github.com/systemd/systemd/issues/18791 Whether it was or wasn't connected... ... the spice agent issue in F34 (noticable as a F34 guest VM not releasing the cursor) is also now fixed. |