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.
Bug 1469399 - RFE: Use Type=forking instead of Type=simple in usbguard.service unit
Summary: RFE: Use Type=forking instead of Type=simple in usbguard.service unit
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: usbguard
Version: 7.4
Hardware: All
OS: Linux
medium
low
Target Milestone: pre-dev-freeze
: 7.5
Assignee: Jiří Vymazal
QA Contact: Jiri Jaburek
URL:
Whiteboard:
Depends On: 1460156
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-11 08:20 UTC by Daniel Kopeček
Modified: 2018-04-10 17:35 UTC (History)
4 users (show)

Fixed In Version: usbguard-0.7.0-4.el7
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1846885 (view as bug list)
Environment:
Last Closed: 2018-04-10 17:35:01 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
proposed patch (15.85 KB, patch)
2017-08-24 07:12 UTC, Jiří Vymazal 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Github dkopecek usbguard pull 200 0 None closed Added classical daemonization (double fork) procedure 2020-09-11 02:03:25 UTC
Red Hat Bugzilla 1460156 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Product Errata RHBA-2018:0942 0 None None None 2018-04-10 17:35:08 UTC

Internal Links: 1460156

Description Daniel Kopeček 2017-07-11 08:20:59 UTC 
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
Comment 1 Orion Poplawski 2017-07-24 19:57:58 UTC 
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.
Comment 2 Daniel Kopeček 2017-07-25 06:12:18 UTC 
(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?
Comment 3 Orion Poplawski 2017-07-25 16:00:09 UTC 
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.
Comment 4 Jiri Jaburek 2017-08-15 09:45:11 UTC 
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.
Comment 5 Jiří Vymazal 2017-08-24 07:12:49 UTC 
Created attachment 1317471 [details]
proposed patch
Comment 6 Jiří Vymazal 2017-08-24 07:13:30 UTC 
Added proposed patch (already accepted & merged upstream)
Comment 13 errata-xmlrpc 2018-04-10 17:35:01 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.