Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D dbus
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 262
    • Issues 262
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 33
    • Merge requests 33
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • dbusdbus
  • dbus
  • Issues
  • #70
Closed
Open
Issue created Jun 11, 2012 by Bugzilla Migration User@bugzilla-migration

Need to provide standardized way to disable services started by dbus

Submitted by bas..@..oo.com

Assigned to D-Bus Maintainers

Link to original bug (#50955)

Description

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

Version: 1.5

Assignee
Assign to
Time tracking