Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The usbguard systemd service unit is currently implemented as a Type=simple service. For better user experience, this should be changed to Type=forking as that will allow systemctl to report an error immediately in case the service fails to start.
Forking is currently not implemented in usbguard-daemon, which is the reason for Type=simple usage in the unit file.
Version-Release number of selected component (if applicable):
usbguard-0.7.0-3.el7
How reproducible:
Always.
Steps to Reproduce:
1. Create an invalid /etc/usbguard/rules.conf file
2. systemctl start usbguard.service
Actual results:
No error reported by systemctl. Admin has to check the status via systemctl status usbguard or journalctl -u usbguard.
Expected results:
systemctl reports a failure immediately.
Additional info:
https://bugzilla.redhat.com/show_bug.cgi?id=1460156#c15
This doesn't seem right. Type=simple is generally the preferred way for systemd services to start. If usbguard isn't failing properly, that seems to be an error in usbguard.
(In reply to Orion Poplawski from comment #1)
> This doesn't seem right. Type=simple is generally the preferred way for
> systemd services to start. If usbguard isn't failing properly, that seems
> to be an error in usbguard.
Please define what it means failing properly. usbguard-daemon returns a non-zero return code in this case.
Why is Type=simple a generally preferred way?
I've understood that systemd has much better control over a simple service - because it is still the parent. But, yes, systemctl start can return 0 for a failed start. Perhaps adding notification support would help, but not sure.
The likely reason (I haven't done much research) is that with type=forking, systemd can just wait for the process to daemonize itself and if the process fails some config/state/other sanity check before the daemonization, systemd can detect it and collect its exit code.
With type=simple, the process will potentially never end, so instead of waiting some arbitrary amount of seconds after start to confirm it doesn't crash, systemd likely just waits for its internal daemonization logic to succeed and stops caring afterwards.
The service status should still be correctly tracked in both cases, just the service starting logic might not care long enough.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2018:0942