Discussion:
Bug#852108: usbguard: fails to start after installation: "ERROR: Configuration: /etc/usbguard/rules.conf: usbguard::Exception"
(too old to reply)
i***@debian.org
2017-01-21 18:20:02 UTC
Permalink
Package: usbguard
Version: 0.6.2+ds1-1
Severity: normal

Hi,

after installing the package, usbguard.service fails to start:

systemd[1]: Started USBGuard daemon.
usbguard-daemon[30357]: [1485021770.799] (E) ERROR: Configuration: /etc/usbguard/rules.conf: usbguard::Exception
systemd[1]: usbguard.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: usbguard.service: Unit entered failed state.
systemd[1]: usbguard.service: Failed with result 'exit-code'.

It looks like the default config depends on a file that doesn't exist
(yet). Any reason why we should not create an empty rules.conf in
postinst if there's none (and remove it on purge)?

Cheers,
--
intrigeri
Muri Nicanor
2017-01-24 15:40:02 UTC
Permalink
control: tags -1 + pending

Hi intrigeri,

thanks a lot for spotting this. You're totally right, there should be at
least an empty rules.conf file. I'll fix that.

cheers,
muri
Muri Nicanor
2017-02-04 18:00:02 UTC
Permalink
control: tags -1 + moreinfo unreproducible

hi again,
Post by i***@debian.org
systemd[1]: Started USBGuard daemon.
usbguard-daemon[30357]: [1485021770.799] (E) ERROR: Configuration: /etc/usbguard/rules.conf: usbguard::Exception
systemd[1]: usbguard.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: usbguard.service: Unit entered failed state.
systemd[1]: usbguard.service: Failed with result 'exit-code'.
i'm actually not able to reproduce the bug. if i install usbguard on a
clean stretch installation i can start usbguard[0] without having an
Post by i***@debian.org
usbguard-daemon.conf
# RuleFile=/path/to/rules.conf
RuleFile=/etc/usbguard/rules.conf
● usbguard.service - USBGuard daemon
Loaded: loaded (/lib/systemd/system/usbguard.service; enabled;
vendor preset: enabled)
Active: active (running) since Sat 2017-02-04 12:44:55 EST; 5s ago
Docs: man:usbguard-daemon(8)
Main PID: 1130 (usbguard-daemon)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/usbguard.service
└─1130 /usr/sbin/usbguard-daemon -k -c /etc/usbguard
/usbguard-daemon.conf
Feb 04 12:44:55 debian systemd[1]: Started USBGuard daemon.
was there maybe a file without read permissions? or with maybe with
rules that made usbguard choke?

(nontheless i'll still add the rules.conf in the postinst script)

cheers,
muri

[0] i found another bug, that i'll file right away
intrigeri
2017-02-07 11:00:02 UTC
Permalink
Control: tag -1 - moreinfo
Control: retitle -1 usbguard.service is started three times on initial installation and only the 3rd time succeeds

Hi,
Post by Muri Nicanor
control: tags -1 + moreinfo unreproducible
i'm actually not able to reproduce the bug. if i install usbguard on a
clean stretch installation i can start usbguard[0] without having an
Post by i***@debian.org
usbguard-daemon.conf
# RuleFile=/path/to/rules.conf
RuleFile=/etc/usbguard/rules.conf
● usbguard.service - USBGuard daemon
Loaded: loaded (/lib/systemd/system/usbguard.service; enabled;
vendor preset: enabled)
Active: active (running) since Sat 2017-02-04 12:44:55 EST; 5s ago
Docs: man:usbguard-daemon(8)
Main PID: 1130 (usbguard-daemon)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/usbguard.service
└─1130 /usr/sbin/usbguard-daemon -k -c /etc/usbguard
/usbguard-daemon.conf
Feb 04 12:44:55 debian systemd[1]: Started USBGuard daemon.
Looking closer, I see the same here, *but* what happens on
installation is weird: usbguard.service is started no less than
3 times, and only the third attempt works. It looks somewhat related
to usbguard-dbus.service:

Feb 07 11:38:41 sid-desktop systemd[1]: Started USBGuard daemon.
Feb 07 11:38:41 sid-desktop systemd[1]: Starting USBGuard D-Bus Service...
Feb 07 11:38:41 sid-desktop usbguard-daemon[3693]: [1486463921.919] (E) ERROR: Configuration: /etc/usbguard/rules.conf: usbguard::Exception
Feb 07 11:38:41 sid-desktop systemd[1]: usbguard.service: Main process exited, code=exited, status=1/FAILURE
Feb 07 11:38:41 sid-desktop systemd[1]: usbguard.service: Unit entered failed state.
Feb 07 11:38:41 sid-desktop systemd[1]: usbguard.service: Failed with result 'exit-code'.
Feb 07 11:38:41 sid-desktop systemd[1]: Started USBGuard D-Bus Service.
Feb 07 11:38:42 sid-desktop systemd[1]: usbguard.service: Service hold-off time over, scheduling restart.
Feb 07 11:38:42 sid-desktop systemd[1]: Stopped USBGuard daemon.
Feb 07 11:38:42 sid-desktop systemd[1]: Started USBGuard daemon.
Feb 07 11:38:42 sid-desktop systemd[1]: Stopping USBGuard D-Bus Service...
Feb 07 11:38:42 sid-desktop systemd[1]: Stopped USBGuard D-Bus Service.
Feb 07 11:38:42 sid-desktop systemd[1]: Starting USBGuard D-Bus Service...
Feb 07 11:38:42 sid-desktop usbguard-daemon[3704]: [1486463922.084] (E) ERROR: Configuration: /etc/usbguard/rules.conf: usbguard::Exception
Feb 07 11:38:42 sid-desktop systemd[1]: usbguard.service: Main process exited, code=exited, status=1/FAILURE
Feb 07 11:38:42 sid-desktop systemd[1]: usbguard.service: Unit entered failed state.
Feb 07 11:38:42 sid-desktop systemd[1]: usbguard.service: Failed with result 'exit-code'.
Feb 07 11:38:42 sid-desktop systemd[1]: Started USBGuard D-Bus Service.
Feb 07 11:38:42 sid-desktop systemd[1]: usbguard.service: Service hold-off time over, scheduling restart.
Feb 07 11:38:42 sid-desktop systemd[1]: Stopping USBGuard D-Bus Service...
Feb 07 11:38:42 sid-desktop systemd[1]: Stopped USBGuard daemon.
Feb 07 11:38:42 sid-desktop systemd[1]: Started USBGuard daemon.
Feb 07 11:38:42 sid-desktop systemd[1]: Stopped USBGuard D-Bus Service.
Feb 07 11:38:42 sid-desktop systemd[1]: Starting USBGuard D-Bus Service...
Feb 07 11:38:42 sid-desktop systemd[1]: Started USBGuard D-Bus Service.

So in the end the service is started successfully, but still I wonder
if this strange behavior is highlighting something wrong somewhere
deeper, that could bite us in the future.

Retitling accordingly. Feel free to downgrade severity.
Post by Muri Nicanor
(nontheless i'll still add the rules.conf in the postinst script)
Sounds good!

Cheers,
--
intrigeri
Florent Rougon
2019-12-18 12:40:02 UTC
Permalink
Hello,

Thanks for your work on this package! This bug has the 'pending' tag
since January 24, 2017. Maybe the fix is not pending anymore?

Thanks & regards
--
Florent
Loading...