Bug 50955 - Need to provide standardized way to disable services started by dbus
Summary: Need to provide standardized way to disable services started by dbus
Status: RESOLVED MOVED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.5
Hardware: All All
: medium enhancement
Assignee: D-Bus Maintainers
QA Contact: D-Bus Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-11 01:56 UTC by basjetimmer
Modified: 2019-01-31 10:26 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description basjetimmer 2012-06-11 01:56:23 UTC
Currently there does not appear to be any official, documented way to control which services dbus starts at launch. The only methods to disable a service right now are fairly hackish and don't survive a package upgrade/reinstall. These methods are to rename, or remove the .service file (normally located at /usr/share/dbus-1/services). Also, when removing the file, any future frontend for controlling dbus services won't be able to suggest the service for re-enabling, as the .service file is no longer there.

I suggest adding an extra key to the service file 'Enabled=' with possible values 'Yes' or 'No'. The key should be optional and default to Yes if not found, so existing .service files will still work. Obviously dbus needs to be changed to parse this key, and respect its value.

I also suggest an optional key 'Description=' so service providers can describe what the service does. This description could then be read by a possible frontend and shown to users considering disabling a service.

Thanks,
Bas Timmer
Comment 1 Simon McVittie 2012-06-11 03:28:21 UTC
Which D-Bus services do you want to disable in this way? Can't you just uninstall those services?

I would like to be careful about the ability to disable activatable D-Bus services, since it undermines package dependencies: if you have a package installed that needs a service com.example.Foo, it would normally have "Depends: foo-daemon" (dpkg) or "Requires: foo-daemon" (RPM). If activatable services can be disabled, this dependency is no longer sufficient to ensure that the com.example.Foo service can be obtained, and the depending package doesn't necessarily work any more.

Unlike init-launched daemons, D-Bus services are only launched if something communicates with them: services that aren't requested don't get launched. As a result, whenever you disable a service that would normally be launched, you're likely to be breaking an application that depends on that service.

(In reply to comment #0)
> I suggest adding an extra key to the service file 'Enabled=' with possible
> values 'Yes' or 'No'.

For session services, a service file in ~/.local/share/dbus-1/services takes precedence over the one in /usr/share, so your Enabled idea could work.

For system services, that isn't actually enough: package upgrades will (and should) still overwrite the service file in /usr/share. If you need to disable system services, the mechanism to do so is system configuration, so it needs to be in /etc. For instance, it could work like systemd's "/etc overrides /lib" semantics.
Comment 2 Simon McVittie 2012-06-11 03:33:50 UTC
(In reply to comment #1)
> I would like to be careful about the ability to disable activatable D-Bus
> services, since it undermines package dependencies: if you have a package
> installed that needs a service com.example.Foo, it would normally have
> "Depends: foo-daemon" (dpkg) or "Requires: foo-daemon" (RPM).

In Debian-derived distributions, if you have a package installed that *can* use a service com.example.Foo but works OK without it, it should have a "Recommends" or "Suggests" relationship with foo-daemon instead of "Depends", allowing you to remove foo-daemon. I don't know whether these weaker dependencies are possible in non-dpkg package management systems yet.
Comment 3 basjetimmer 2012-06-11 04:17:14 UTC
(In reply to comment #1)
> Which D-Bus services do you want to disable in this way? Can't you just
> uninstall those services?

Well, in Fedora 17, I wanted to stop zeitgeist from running. Of course I first tried to uninstall but it tried to take the whole of KDE with it, so that was no option. After the service didn't show up in systemctl or chkconfig, I found it in /usr/share/dbus-1/services. After removing it from there, the service stopped running and nothing appears to be broken.

> 
> I would like to be careful about the ability to disable activatable D-Bus
> services, since it undermines package dependencies: if you have a package
> installed that needs a service com.example.Foo, it would normally have
> "Depends: foo-daemon" (dpkg) or "Requires: foo-daemon" (RPM). If activatable
> services can be disabled, this dependency is no longer sufficient to ensure
> that the com.example.Foo service can be obtained, and the depending package
> doesn't necessarily work any more.

Yes, I understand. That is part of the reason I also mentioned the 'description' key. For example, in KDE you can disable the khotkeys daemon, but in the dialog where you do that the description used to say something like 'Note: if you disable this daemon keyboard shortcuts will no longer work'. And then the user can decide. Anyway, any installed services will/should be enabled by default, so I'd say you can assume a user who explicitly disables something does so for a reason, and if things instantly break, he/she will remember disabling a service 3 seconds earlier and hopefully have the common sense to reactivate it.

> 
> Unlike init-launched daemons, D-Bus services are only launched if something
> communicates with them: services that aren't requested don't get launched. As a
> result, whenever you disable a service that would normally be launched, you're
> likely to be breaking an application that depends on that service.
> 
> (In reply to comment #0)
> > I suggest adding an extra key to the service file 'Enabled=' with possible
> > values 'Yes' or 'No'.
> 
> For session services, a service file in ~/.local/share/dbus-1/services takes
> precedence over the one in /usr/share, so your Enabled idea could work.
> 
> For system services, that isn't actually enough: package upgrades will (and
> should) still overwrite the service file in /usr/share. If you need to disable
> system services, the mechanism to do so is system configuration, so it needs to
> be in /etc. For instance, it could work like systemd's "/etc overrides /lib"
> semantics.

Right, I hadn't realized that (I actually only had session services in mind), but that's true of course. Do I understand correctly that creating an empty 'foo.service' file in ~/.local/share/dbus-1/services effectively disables the foo service by taking precedence over the (working) foo.service file in /usr/share? Because that would, for session services, actually be a nicer solution than removing the file from the root-owned location (and it would survives updates).

I'm not sure about the weaker dependencies, or suggested packages in rpm, but maybe I should file a bug against kde for depending on zeitgeist anyway...

Thanks!
Comment 4 GitLab Migration User 2018-10-12 21:14:04 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/70.
Comment 5 AlexJuvion 2019-01-31 10:26:50 UTC
Happy to find guidance and need of providing standardized way to disable services started by dbus and methods to disable a service immediately which are justly hackish and don't survive a package upgrade/reinstall.
Alex,
http://www.qualityassignment.co.uk/


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.