Bug 986949

Summary: StopWhenUnneeded does NOT stop service when there is nothing that Wants/Requires/... it
Product: Red Hat Enterprise Linux 7 Reporter: Tomáš Hozza <thozza>
Component: systemdAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED ERRATA QA Contact: Branislav Blaškovič <bblaskov>
Severity: high Docs Contact:
Priority: high    
Version: 7.0CC: bblaskov, harald, jscotka, lnykryn, riehecky, systemd-maint-list
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-208-12.el7 Doc Type: Bug Fix
Doc Text:
Cause: If service failed during its startup we did not check for other services with StopWhenUnneeded=yes which could be stopped. Consequence: If service failed during its startup, other services with StopWhenUnneeded=yes where not stopped. Fix: Now we are performing that check even for stopping services which were never in running state. Result: If service fails during its startup, other services with StopWhenUnneeded=yes are stopped (of course unless some other running service needs them).
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-05 11:08:40 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:    
Bug Blocks: 1004300    

Description Tomáš Hozza 2013-07-22 13:30:35 UTC
Description of problem:
I want to clean up BIND9 unit files. There is a service (two actually) that need to set up a chroot environment before starting the service. bind services Requires the unit for setting up the chroot. The service for setting up chroot has StopWhenUnneeded=yes so it is stopped (and chroot is cleaned up) if the service that started it stopped/crashed/failed while starting and there is no
other service that Requires it.

The problem is that currently with StopWhenUnneeded=yes the service for setting
up the chroot is not stopped even if there is nothing that Requires it (or any
weaker or different relationship).

Version-Release number of selected component (if applicable):
latest (systemd-204-9.el7.1)

How reproducible:
always

Steps to Reproduce:
-bash-4.2# more /etc/systemd/system/test*
::::::::::::::
/etc/systemd/system/test.service
::::::::::::::
[Unit]
Description=aaa
Requires=testb.service

[Service]
Type=forking
ExecStart=/bin/sleep 50
TimeoutStartSec=3

::::::::::::::
/etc/systemd/system/testb.service
::::::::::::::
[Unit]
Description=aaa
StopWhenUnneeded=yes

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/echo hej
ExecStop=/bin/echo hou

-bash-4.2# systemctl status testb test
testb.service - aaa
    Loaded: loaded (/etc/systemd/system/testb.service; static)
    Active: inactive (dead)


test.service - aaa
    Loaded: loaded (/etc/systemd/system/test.service; static)
    Active: inactive (dead)

-bash-4.2# systemctl start test
Job for test.service failed. See 'systemctl status test.service' and 
'journalctl -xn' for details.

-bash-4.2# systemctl status testb test
testb.service - aaa
    Loaded: loaded (/etc/systemd/system/testb.service; static)
    Active: active (exited) since Thu 2013-07-18 15:34:34 CEST; 7s ago
   Process: 45 ExecStart=/bin/echo hej (code=exited, status=0/SUCCESS)

Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
Jul 18 15:34:34 mycontainer systemd[1]: Started aaa.

test.service - aaa
    Loaded: loaded (/etc/systemd/system/test.service; static)
    Active: failed (Result: timeout) since Thu 2013-07-18 15:34:37 CEST; 
4s ago
   Process: 46 ExecStart=/bin/sleep 50 (code=killed, signal=TERM)

Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
Jul 18 15:34:37 mycontainer systemd[1]: test.service operation timed 
out. Terminating.
Jul 18 15:34:37 mycontainer systemd[1]: Failed to start aaa.
Jul 18 15:34:37 mycontainer systemd[1]: Unit test.service entered failed 
state.

Actual results:
The service with StopWhenUnneeded=yes is NOT stopped if not needed.

Expected results:
The service with StopWhenUnneeded=yes is stopped if not needed.

Additional info:
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012123.html
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012141.html

Comment 2 Harald Hoyer 2013-10-28 08:50:29 UTC
Type=forking
ExecStart=/bin/sleep 50

That does not go together well... sleep is not forking

Comment 3 Tomáš Hozza 2013-10-29 08:02:38 UTC
(In reply to Harald Hoyer from comment #2)
> Type=forking
> ExecStart=/bin/sleep 50
> 
> That does not go together well... sleep is not forking

These are just examples. You can replace sleep with any forking service
that would fail to start in the TimeoutStartSec time range.

Comment 4 Harald Hoyer 2013-11-11 11:51:38 UTC
(In reply to Tomas Hozza from comment #3)
> (In reply to Harald Hoyer from comment #2)
> > Type=forking
> > ExecStart=/bin/sleep 50
> > 
> > That does not go together well... sleep is not forking
> 
> These are just examples. You can replace sleep with any forking service
> that would fail to start in the TimeoutStartSec time range.

yes, sorry, you are right. That service was just for the test case to prove the bug.

Comment 5 Lennart Poettering 2014-02-19 02:59:35 UTC
Fixed in git.

Comment 6 RHEL Program Management 2014-03-22 06:43:44 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 7 Tomáš Hozza 2014-03-24 07:21:24 UTC
(In reply to Lennart Poettering from comment #5)
> Fixed in git.

And what about RHEL 7? Will it be fixed there (if not already)?

Comment 8 Lukáš Nykrýn 2014-03-24 08:42:06 UTC
This was not a blocker, so it will be in 7.1.

Comment 14 Branislav Blaškovič 2015-01-07 11:59:08 UTC
Switching to VERIFIED according to comment #13.

Comment 16 errata-xmlrpc 2015-03-05 11:08:40 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://rhn.redhat.com/errata/RHBA-2015-0509.html