(In reply to Patrick Uiterwijk from comment #0)
> Description of problem:
> The name of the systemd service specified in
> /usr/share/dbus-1/system-services/org.usbguard.service is incorrect.
> 
> Version-Release number of selected component (if applicable):
> usbguard-0.6.2-1.fc25.x86_64
> usbguard-dbus-0.6.2-1.fc25.x86_64
> 
> How reproducible:
> Consistent
> 
> Steps to Reproduce:
> 1. Install usbguard usbguard-dbus
> 2. See /usr/share/dbus-1/system-services/org.usbguard.service
> 
> Actual results:
> SystemdService=dbus-org.usbguard.service
> 
> Expected results:
> SystemdService=usbguard-dbus.service
> 
> Additional info:
> Because of this, the org.usbguard dbus path is not actually available:
> dbus.exceptions.DBusException: org.freedesktop.systemd1.NoSuchUnit: Unit
> dbus-org.usbguard.service not found.
> 
> Updating the unit name in the dbus configuration fixes it.

There's an Alias= in the usbguard-dbus.service:

---snip---

[Install]
...
Alias=dbus-org.usbguard.service

---snip---

Does it not work properly?

Seems like it doesn't based on the error I got from dbus when actually calling it..

Just install usbguard-dbus, and run gdbus introspect --system --dest org.usbguard --object-path /org/usbguard --recurse.

I am getting: Error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit dbus-usbguard.service not found.

(In reply to Patrick Uiterwijk from comment #2)
> Seems like it doesn't based on the error I got from dbus when actually
> calling it..
> 
> Just install usbguard-dbus, and run gdbus introspect --system --dest
> org.usbguard --object-path /org/usbguard --recurse.
> 
> I am getting: Error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit
> dbus-usbguard.service not found.

Did you enable the usbguard-dbus service? i.e.:

# systemctl enable usbguard-dbus

If I do that on my system, then it works as expected.

I did not (since editing the unit name in the dbus configuration worked), but even after that it doesn't work.

It works if I *start* usbguard-dbus, or if I reboot after enabling it (because then it's started), but isn't the whole point of the dbus configuration file to automatically start the service if it's stopped? (and as such, the enabling would also not be required?)


[root@krbadmin puiterwijk]# systemctl enable usbguard-dbus
Created symlink /etc/systemd/system/dbus-org.usbguard.service → /usr/lib/systemd/system/usbguard-dbus.service.
Created symlink /etc/systemd/system/multi-user.target.wants/usbguard-dbus.service → /usr/lib/systemd/system/usbguard-dbus.service.
[root@krbadmin puiterwijk]# gdbus introspect --system --dest org.usbguard --object-path /org/usbguard --recurse
Error: GDBus.Error:org.freedesktop.systemd1.NoSuchUnit: Unit dbus-usbguard.service not found.

Okay, so if I correctly revert the change I made to the dbus config file (to dbus-org.usbguard.service instead of forgetting the org.) it works.

However, I'm still confused why I need to enable it (to make the alias), if the whole point of the dbus config file is to automatically start the service when it's accessed.

(In reply to Patrick Uiterwijk from comment #5)
> However, I'm still confused why I need to enable it (to make the alias), if
> the whole point of the dbus config file is to automatically start the
> service when it's accessed.

That is a good point. I should probably implement some sort of inactivity timeout and exit the service if it's not needed. Or maybe this something systemd could do. I don't know at this point.

(In reply to Daniel Kopeček from comment #6)
> (In reply to Patrick Uiterwijk from comment #5)
> > However, I'm still confused why I need to enable it (to make the alias), if
> > the whole point of the dbus config file is to automatically start the
> > service when it's accessed.
> 
> That is a good point. I should probably implement some sort of inactivity
> timeout and exit the service if it's not needed. Or maybe this something
> systemd could do. I don't know at this point.

After some more thinking about this, I don't think there's anything to fix here. 

An inactivity timeout doesn't seem to be a useful thing after all, as it might lead to confusing situations / race conditions where a client calls a method the moment the service is shutting down.

The requirement to enable the service seems to be ok to me, as it is simply a way to say that the service should be enabled and available. As a maintainer, I'm not supposed to enable the service by default during the installation phase...