GNOME Bugzilla – Bug 770786
systemd user units are not used by default
Last modified: 2021-05-26 22:26:24 UTC
Hi, I noticed that the latest 1.9.1 release added systemd user units. It seems only tracker-store.service is actually active though. Those services are triggered via the D-Bus interface but also have an xdg autostart file, and only the autostart file for tracker-store triggers the start of tracker-store.service, all others start the service directly: $ grep Exec /etc/xdg/autostart/tracker-* /etc/xdg/autostart/tracker-extract.desktop:Exec=/usr/lib/tracker/tracker-extract /etc/xdg/autostart/tracker-miner-apps.desktop:Exec=/usr/lib/tracker/tracker-miner-apps /etc/xdg/autostart/tracker-miner-fs.desktop:Exec=/usr/lib/tracker/tracker-miner-fs /etc/xdg/autostart/tracker-miner-user-guides.desktop:Exec=/usr/lib/tracker/tracker-miner-user-guides /etc/xdg/autostart/tracker-store.desktop:Exec=gdbus call -e -d org.freedesktop.DBus -o /org/freedesktop/DBus -m org.freedesktop.DBus.StartServiceByName org.freedesktop.Tracker1 0 I'm a bit uncertain if adding dbus calls to all xdg autostart files is the correct solution or if those units should be hooked up via WantedBy= in say default.target. In any case, just wanted to raise this issue.
Any thoughts on this? Is there a reason tracker-extract actually needs an autostart file? I suppose it get's started on demand via D-Bus service activation. For the other tracker-miner-* services, should we simply use the same "hack" as tracker-store, i.e. trigger the start via gdbus?
(In reply to Michael Biebl from comment #1) > Any thoughts on this? > > Is there a reason tracker-extract actually needs an autostart file? I > suppose it get's started on demand via D-Bus service activation. Not really... when it was made a full blown miner, it also became a permanent daemon. Nothing prevents it though from having an intermitent lifetime, and there's already some infrastructure pieces in master that could help there. > > For the other tracker-miner-* services, should we simply use the same "hack" > as tracker-store, i.e. trigger the start via gdbus? I'd tbh go the other way around... Have miners not started by default, and if anything requires from these, they should use the libtracker-manager APIs to ensure they're up and running, that'd require some projects to actually realize that API exists though :).
err, libtracker-control I meant
Carlos, a related issue was filed downstream at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865496 I wonder, whether we shouldn't just drop the xdg autostart files for the miners and tracker-extract, and let tracker-store trigger the start of those services.
Yes, I think dropping those is a good idea. The sandboxing stuff at wip/carlosg/domain-ontologies pretty much requires clients to use libtracker-control to ensure their set of daemons is present. Given this is a requirement for apps that want to use Tracker inside a sandbox and not matter of education anymore, I think we can rely on them doing this too outside sandboxes and have the miner services started on demand whenever anything requires them.
Is it too late for this to happen for 3.26? Thanks.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/tracker/-/issues/ Thank you for your understanding and your help.