Discussion:
General question about dbus-activatable services
Add Reply
Christian Rebischke
2017-02-16 01:01:29 UTC
Reply
Permalink
Raw Message
Hello,
I have the following problem. I use X with only a tiling manager (DWM)
on Arch Linux. Therefore I don't have imsettings nor im-chooser. (And I
really don't want to install im-chooser). I would like to start
ibus-daemon automatically on login in my user session.

I wrote a systemd service file for it:

# /etc/systemd/user/ibus.service
[Unit]
Description=ibus daemon
Documentation=man:ibus-daemon(1)

[Service]
Type=forking
ExecStart=/usr/bin/ibus-daemon --xim -d

[Install]
WantedBy=default.target


And made a PR for it here:
https://github.com/ibus/ibus/pull/1896

But it was rejected, due to the fact that a dbus-activatable service for
ibus exists.

Now is my question, how can I trigger this service? I expected that I need
to send a call command via busctl directly to org.freedesktop.IBus but
according to my `busctl list` output this dbus service doesn't exist
(although it's there under
/usr/share/dbus-1/services/org.freedesktop.IBus.service).

How can I register this service to dbus? And how would I start this
dbus-activatable service on login? Would I use a systemd.service for it?
How would it look like? Would I simply swap the ExecStart line against a
line with busctl that calls the dbus-activatable ibus service?

Best regards,

Chris
Simon McVittie
2017-02-16 11:54:35 UTC
Reply
Permalink
Raw Message
Post by Christian Rebischke
I would like to start
ibus-daemon automatically on login in my user session.
...
Post by Christian Rebischke
But it was rejected, due to the fact that a dbus-activatable service for
ibus exists.
If there is a D-Bus service already, the way to get it started
by `systemd --user` is to link the two together, something like this:
<https://github.com/flatpak/xdg-desktop-portal-gtk/pull/52>
Having duplication between D-Bus session services and systemd user
services without linking them together with `SystemdService` is likely
to be harmful (it'll get started twice under at least some circumstances).

As a side-effect, doing something similar to that xdg-desktop-portal-gtk
PR will give you a service that you can enable using a symbolic link in
~/.config/systemd/user/default.target.wants.

I've commented on the ibus bug.

S
Jonathan de Boyne Pollard
2017-02-16 14:02:04 UTC
Reply
Permalink
Raw Message
I would like to start ibus-daemon automatically on login in my user session.
The person who told you that this was unnecessary because ibus already has a way
to run the daemon via "bus activation" is wrong. There are various good reasons
to avoid bus activation, especially if one has a proper service management
subsystem available. You are actually a fair portion of the way there. You are
missing a couple of things, though. Your systemd service unit is wrong, and
your DBus service definition is incomplete.

The goal is to connect the DBus broker with service management. The way that
this all hangs together (in the wider world outwith systemd and Linux, as well)
is that a service client tells the DBus broker to auto-start the DBus service,
the DBus broker tells the service manager to start the service process, and the
service is marked as "ready" when it has registered a specific name with the
broker.

* http://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html
* http://jdebp.eu./Softwares/nosh/guide/per-user-dbus-demand-start.html

To achieve this, you first need to correct your systemd service unit. The type
should be "bus", not "forking". This tells systemd that the service is "ready"
when it has registered a particular name. You also need to tell systemd this
name. Moreover, you need to tell the daemon program not to erroneously fork in
[Service]
Type=bus
ExecStart=/usr/bin/ibus-daemon --xim
BusName=org.freedesktop.IBus
You also need to tell the DBus broker not to attempt to directly run the daemon,
but rather to run it indirectly by telling the service manager to start it.
[D-BUS Service]
Name=org.freedesktop.IBus
SystemdService=ibus.service
The DBus broker, as long as it has been invoked in such a way that it "knows"
that there's a service manager there, talks to the service manager to activate
the service. There's nothing stopping you from enabling and starting it
yourself in the normal way (using the --user option to systemctl, remember) if
you don't want to rely upon on-demand activation by DBus service clients.
Loading...