Bug 1413964 - systemctl exits with status 0 on a nonexisting service unit
Summary: systemctl exits with status 0 on a nonexisting service unit
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: Branislav Blaškovič
: 1397354 (view as bug list)
Depends On:
Blocks: 74systemd
TreeView+ depends on / blocked
Reported: 2017-01-17 13:01 UTC by Zdenek Pytela
Modified: 2020-12-14 08:01 UTC (History)
4 users (show)

Fixed In Version: systemd-219-31.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2017-08-01 09:14:52 UTC
Target Upstream Version:

Attachments (Terms of Use)
strace of systemctl is-enabled iscsi (30.62 KB, text/plain)
2017-01-17 13:01 UTC, Zdenek Pytela
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2915421 0 None None None 2017-02-08 15:13:40 UTC
Red Hat Product Errata RHBA-2017:2297 0 normal SHIPPED_LIVE systemd bug fix and enhancement update 2017-08-01 12:40:16 UTC

Description Zdenek Pytela 2017-01-17 13:01:01 UTC
Created attachment 1241770 [details]
strace of systemctl is-enabled iscsi

Description of problem:
Under some conditions, systemctl reports an error on a nonexisting service unit, but exits with exit status 0. Therefore also subsequent actions based on exit status fail. It happens during a kickstart update with selinux enforcing, most likely only when selinux-policy package is updated.

Version-Release number of selected component (if applicable):

How reproducible:
always on customer's site

Steps to Reproduce:
1. On a satellite server, prepare updates to deploy.
2. Add setenforce 1 to %post section
3. Execute
systemctl is-enabled nonexisting; echo $?

Actual results:
Failed to get unit file state for nonexisting.service: No such file or directory

Expected results:
Failed to get unit file state for nonexisting.service: No such file or directory

Additional info:
Not sure if it is relevant, but the current working theory is that it happens only when selinux-policy package is part of the update suite. Additionally, after leaving the chrooted environment, no command can be run any longer. A known workaround is to execute setenforce 0.

Comment 5 Jan Synacek 2017-01-23 11:47:59 UTC

Test build incoming.

Comment 9 Jan Synacek 2017-01-24 14:54:57 UTC
*** Bug 1397354 has been marked as a duplicate of this bug. ***

Comment 10 Lukáš Nykrýn 2017-01-25 09:31:49 UTC
fix merged to upstream staging branch ->
-> post

Comment 11 Branislav Blaškovič 2017-02-02 14:23:53 UTC
Qa acking for 7.4

Comment 14 errata-xmlrpc 2017-08-01 09:14:52 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.


Note You need to log in before you can comment on or make changes to this bug.