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: | usbguard | Assignee: | Jiří Vymazal <jvymazal> | ||||
Status: | CLOSED ERRATA | QA Contact: | Jiri Jaburek <jjaburek> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.4 | CC: | jjaburek, jvymazal, mthacker, orion | ||||
Target Milestone: | pre-dev-freeze | Keywords: | 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
Daniel Kopeček
2017-07-11 08:20:59 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. (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. Created attachment 1317471 [details]
proposed patch
Added proposed patch (already accepted & merged upstream) 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 |