Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add org.opensuse.RebootMgr.service for DBus activation #18

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Vogtinator
Copy link
Member

By using dbus activation, rebootmgrd is started on demand instead of causing

Error: The name org.opensuse.RebootMgr was not provided by any .service files

By using dbus activation, rebootmgrd is started on demand instead of causing

Error: The name org.opensuse.RebootMgr was not provided by any .service files
@Vogtinator
Copy link
Member Author

@@ -0,0 +1,5 @@
[D-BUS Service]
Name=org.opensuse.RebootMgr
Exec=/usr/sbin/rebootmgrd
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be /bin/false so dbus-daemon itself does not activate the service. To enable autoactivation you can add the Alias=dbus-org.opensuse.RebootMgr.service to the [install] section of the service file. That way systemd takes care and would not be used of the service gets disabled.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, not sure whether that's enough. There's also the SystemdService property. The documentation says:

For bus-activatable services, do not include a [Install] section in the systemd service file, but use the SystemdService= option in the corresponding DBus service file

In any case, it still conflicts with the the current design philosophy as rebootmgrctl is-active is meant to tell whether rebootmgr is meant to be used...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, not sure whether that's enough. There's also the SystemdService property. The documentation says: ...

Actually, that would work. systemd/systemd#21520 only applies if the unit exists, so a missing unit should result in the proper ActivationFailed signal still, not a 30s timeout.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants