6

Recently I noticed that the rtkit-daemon process running on my Debian 10.4 machine may be interferring with a custom server application on that machine. So I wanted to disable that realtime kit daemon like this:

$ sudo systemctl stop rtkit-daemon.service
$ sudo systemctl disable rtkit-daemon.service

That correctly stopped (and disabled) the rtkit-daemon process. However, after a while I noticed that it is running again, and in syslog I found the following lines:

Jun 12 16:15:12 box-63 dbus-daemon[453]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.6746' (uid=1000 pid=11857 comm="python pipecheck.py")
Jun 12 16:15:12 box-63 systemd[1]: Starting RealtimeKit Scheduling Policy Service...
Jun 12 16:15:12 box-63 dbus-daemon[453]: [system] Successfully activated service 'org.freedesktop.RealtimeKit1'
Jun 12 16:15:12 box-63 systemd[1]: Started RealtimeKit Scheduling Policy Service.

That python pipecheck.py is our custom application.
Why does D-Bus want to start the realtime kit for our application in the first place?

Anyway, so apparently the dbus-daemon has restarted the rtkit-daemon.
How can i prevent that and disable the realtime kit daemon for good?

1
  • 1
    Why has this question been downvoted?
    – Matthias
    Jun 15, 2020 at 10:33

2 Answers 2

9

Welcome to Desktop Bus bus activation! It is a pain, and should be avoided.

A Desktop Bus client (of some kind) is asking the Desktop Bus broker for communication with the org.freedesktop.RealtimeKit1 D-Bus server. When the rtkit-daemon program is running, it registers itself with the D-Bus broker as this name. When it is not running, the broker invokes D-Bus bus activation.

When a client asks the D-Bus broker this in such circumstances, the broker looks at what is specfied in a org.freedesktop.RealtimeKit1.service file. (This is not a systemd service unit file, but a D-Bus configuration file living somewhere under /usr/{local/,}share/dbus-1/system-services/, D-Bus also using the .service extension.) The broker learns from this file that on only systemd systems the org.freedesktop.RealtimeKit1 server is managed as a rtkit-daemon.service systemd service.

The broker speaks to systemd over the same Desktop Bus, using an idiosyncratic and undocumented org.freedesktop.systemd1.Activator D-Bus service name, asking it to activate the rtkit-daemon.service systemd service with an ActivationRequest message. This undocumented activation function has no notion of only activating the service if enabled. It always activates the service, even if it is disabled.

So, ironically, you cannot disable rtkit-daemon using the obvious method of disabling it, the disable command. You can instead:

  • … override the org.freedesktop.RealtimeKit1.service file with one of your own that contains no ways to activate the org.freedesktop.RealtimeKit1 D-Bus server;
  • … find out what D-Bus client is asking for org.freedesktop.RealtimeKit1, with busctl monitor, and stop it; or
  • mask the rtkit-daemon.service systemd service, so that systemd itself does not know how to activate it even if the Desktop Bus broker requests its activation via the idiosyncratic and undocumented API.

This is one reason that my system-control has a reset verb (which starts/stops a service according to its current enable/disable state) and my replacement dbus-daemon-launch-helper invokes system-control reset rather than system-control activate.

Further reading

2
  • Found out the hard way that you can't mask rtkit-daemon.service for a user, only for the entire system. systemctl --user doesn't even see rtkit-daemon.service! How do you go about overriding the DBus activation (your first proposed solution)? Can this be overriden for a single user?
    – usretc
    Jan 3, 2021 at 1:25
  • Ah, you're supposed to be able to override in ~/.local/share/dbus-1/services/org.freedesktop.RealtimeKit1.service. However, I've tried to drop a file in there that "starts" /bin/true, and still the real rtkit-daemon gets activated. I'll ask another question.
    – usretc
    Jan 3, 2021 at 11:27
0

poke it the hard way:

sudo mv /usr/bin/dbus-daemon /usr/bin/dbus-daemonx
sudo ln -s /bin/true /usr/bin/dbus-daemon

you could also remove the original file and get it back by reinstalling the package...

the same aproach is working for other unwanted stuff^^

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .