USBGuard daemon won't start at booting.

[vinismm]

Hello,

I've installed usbguard on Mint 20.3 everything works fine, but the service in Systemd don't start at boot...

If I start the machine with a blocked device connected the service won't block it and i have to restart the usbguard.service for it to work as intended.

Does anyone have a solution for that problem?

[hartwork]

Could you elaborate what you mean by "service in Systemd don't start at boot", e.g. what you did to make that happen, is the service enabled, any related error logs etc? Thanks!

[vinismm]

I've installed usbguard with "sudo apt install usbguard" and added the line "allow id 045e:0745" in /etc/usbguard/rules.conf and since the service blocks every device that isn't registered in rules.conf it works fine but if i leave a pendrive connected when i'm booting the system i will be able to use it until i manually restart the usbguard.service.

The following is the result to "systemctl status usbguard.service":
usbguard.service - USBGuard daemon
Loaded: loaded (/etc/systemd/system/usbguard.service; enabled; vendor preset: enabled)
Active: failed (Result: start-limit-hit) since Fri 2023-05-26 10:54:36 -03; 3min 22s ago
Docs: man:usbguard-daemon(8)
Process: 1069 ExecStart=/usr/sbin/usbguard-daemon -k -c /etc/usbguard/usbguard-daemon.conf (code=killed, signal=TERM)
Main PID: 1069 (code=killed, signal=TERM)

mai 26 10:54:36 ESTRES-0524 systemd[1]: Failed to start USBGuard daemon.
mai 26 10:54:36 ESTRES-0524 systemd[1]: usbguard.service: Start request repeated too quickly.
mai 26 10:54:36 ESTRES-0524 systemd[1]: usbguard.service: Failed with result 'start-limit-hit'.
mai 26 10:54:36 ESTRES-0524 systemd[1]: Failed to start USBGuard daemon.
mai 26 10:54:36 ESTRES-0524 systemd[1]: usbguard.service: Start request repeated too quickly.
mai 26 10:54:36 ESTRES-0524 systemd[1]: usbguard.service: Failed with result 'start-limit-hit'.
mai 26 10:54:36 ESTRES-0524 systemd[1]: Failed to start USBGuard daemon.
mai 26 10:54:36 ESTRES-0524 systemd[1]: usbguard.service: Start request repeated too quickly.
mai 26 10:54:36 ESTRES-0524 systemd[1]: usbguard.service: Failed with result 'start-limit-hit'.
mai 26 10:54:36 ESTRES-0524 systemd[1]: Failed to start USBGuard daemon.

[hartwork]

There are some things that are not clear to me yet in your scenario, would be great to fully understand.
Before usbguard is first starting, I would expect the pendrive to still be working because there is nothing actively blocking yet. When you say it needs a restart to usbguard to block the drive and you mean restart rather than start it implies that (1) usbguard was running previously and did not do it's just or (b) it failed to start; your log excerpts above seem to suggest (b), the latter. The question then is what error output usbguard produced during the failed attempts to start. Does sudo journalctl -u usbguard produce any insights that you could share?

[vinismm]

Apparently, the service works when I turn on the machine, but it stops working and starts giving an error in the daemon until it stops with the message: Failed with result 'start-limit-hit'.

Therefore, if I turn on the machine with a connected USB drive (in this case, the USB drive should be blocked), I can use it normally. When I checked the status of the usbguard.service, I noticed the following logs:

usbguard.service: Start request repeated too quickly.
usbguard.service: Failed with result 'start-limit-hit'.
Failed to start USBGuard daemon.

I can only block the use of the USB by restarting the service with the command "sudo systemctl restart usbguard.service."

[vinismm]

Here's a print of the results for sudo journalctl -u usbguard, i hope it helps, i can't understand it by myself so I hope you can find something useful in this.

[hartwork]

I believe this line is the first clue to what's going on:

Apparantly something in your system is killing/stopping usbguard from the outside. If you compair this to running sudo usbguard-daemon -k manually (when the service is not already running), you would see the same lines saying (A) uid=0 pid=11437 result='SUCCESS' and then the daemon keeps going. In your case, something is killing it. I'm not sure what it is, but it seems outside of usbguard. What do you think?

[vinismm]

Thank you for helping, I will identify what is causing this and come back here if I still need assistance.

[hartwork]

@vinismm please come back with an update in any case, so that we can learn from your case and close the ticket as needed. Thank you!

[IPlayZed]

@hartwork I had the same issue on Arch after migrating my PC setup to my laptop:

❯ systemctl status usbguard-dbus.service
× usbguard-dbus.service - USBGuard D-Bus Service
     Loaded: loaded (/usr/lib/systemd/system/usbguard-dbus.service; enabled; preset: disabled)
    Drop-In: /etc/systemd/system/service.d
             └─toplevel-override.conf
     Active: failed (Result: start-limit-hit) since Fri 2024-05-03 16:30:42 CEST; 8min ago
   Duration: 155ms
       Docs: man:usbguard-dbus(8)
    Process: 7280 ExecStart=/usr/bin/usbguard-dbus --system (code=killed, signal=TERM)
   Main PID: 7280 (code=killed, signal=TERM)
        CPU: 29ms

May 03 16:30:42 minefpc systemd[1]: Starting USBGuard D-Bus Service...
May 03 16:30:42 minefpc systemd[1]: Started USBGuard D-Bus Service.
May 03 16:30:42 minefpc systemd[1]: Stopping USBGuard D-Bus Service...
May 03 16:30:42 minefpc systemd[1]: usbguard-dbus.service: Deactivated successfully.
May 03 16:30:42 minefpc systemd[1]: Stopped USBGuard D-Bus Service.
May 03 16:30:42 minefpc systemd[1]: usbguard-dbus.service: Start request repeated too quickly.
May 03 16:30:42 minefpc systemd[1]: usbguard-dbus.service: Failed with result 'start-limit-hit'.
May 03 16:30:42 minefpc systemd[1]: Failed to start USBGuard D-Bus Service.

If I start the it manually as you described:

Apparently something in your system is killing/stopping usbguard from the outside. If you compare this to running sudo usbguard-daemon -k manually (when the service is not already running), you would see the same lines saying (A) uid=0 pid=11437 result='SUCCESS' and then the daemon keeps going. In your case, something is killing it. I'm not sure what it is, but it seems outside of usbguard. What do you think?

The following is the output:

~ 
❯ sudo usbguard-daemon -k
[1714747221.894] (E) Permissions for /etc/usbguard/rules.conf should be 0600
[1714747221.895] (E) Check permissions: /etc/usbguard/rules.conf: Policy may be readable

After issuing sudo chmod 0600 /etc/usbguard/rules.conf, the problem is solved.
So the problem is filesystem permissions, not something else killing the process.

I think as a potential improvement usbguard could output the aforementioned (E) marked messages into the journal so future problems can be identified.

[hartwork]

Hi everyone, the issue is not currently in an actionable state: file permissions are either a usage or a packaging problem, likely not a bug in the actual software. Changes to logging would need a closer look. I'm happy to jump on a voice call with someone if you're convince that there is a bug to fix here, and turn that call into a pull request, to then hopefully be merged by RedHat after, I lack permissions. That's the only thing I can offer time for right now, my e-mail contact is on my GitHub profile.

[IPlayZed]

@hartwork

Hi everyone, the issue is not currently in an actionable state: file permissions are either a usage or a packaging problem, likely not a bug in the actual software.

I couldn't agree more, you might have misunderstood (or did not read the whole comment of mine?) I just think that the error is not represented in the log of the systemd service, so as a potential improvement, error logs should be somehow made sure that they are actually logged by the daemon into the systemd service. This would allow users to correct the underlying configuration issue or help them make an accurate report to downstream, if the issue is cause by for instance incorrect packaging.