Bug 1469399

Summary: RFE: Use Type=forking instead of Type=simple in usbguard.service unit
Product: Red Hat Enterprise Linux 7 Reporter: Daniel Kopeček <dkopecek>
Component: usbguardAssignee: Jiří Vymazal <jvymazal>
Status: CLOSED ERRATA QA Contact: Jiri Jaburek <jjaburek>
Severity: low Docs Contact:
Priority: medium    
Version: 7.4CC: jjaburek, jvymazal, mthacker, orion
Target Milestone: pre-dev-freezeKeywords: FutureFeature, Triaged
Target Release: 7.5   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: usbguard-0.7.0-4.el7 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1846885 (view as bug list) Environment:
Last Closed: 2018-04-10 17:35:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1460156    
Bug Blocks:    
Attachments:
Description Flags
proposed patch none

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