Bug 740703

Summary: Target does not fail when a Required service fails
Product: [Fedora] Fedora Reporter: Garrett Holmstrom <gholms>
Component: systemdAssignee: systemd-maint
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: harald, johannbg, kay, lpoetter, metherid, mschmidt, notting, plautrba
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: systemd-37-11.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-01-30 20:58:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 741115    
Bug Blocks:    

Description Garrett Holmstrom 2011-09-23 02:39:04 UTC
Description of problem:
When a target Requires a service and one attempts to start the target, the target seems to go active without regard to whether or not its dependencies succeed or fail.


Version-Release number of selected component (if applicable):
systemd-26-9.fc15.x86_64

The fine folks in #systemd indicated that this also happens with systemd 35 on F16.


How reproducible:
Always


Steps to Reproduce:
1. Write the following to test.service:
   [Unit]
   Name=test service
   [Service]
   Type=oneshot
   ExecStart=/bin/false

2. Write the following to test.target:
   [Unit]
   Name=test target
   Requires=test.service

3. systemctl --system daemon-reload
4. systemctl start test.target


Actual results:
test.service
	  Loaded: loaded (/etc/systemd/system/test.service)
	  Active: failed since Thu, 22 Sep 2011 19:30:57 -0700; 3s ago
	 Process: 31407 ExecStart=/bin/false (code=exited, status=1/FAILURE)
	  CGroup: name=systemd:/system/test.service

test.target
	  Loaded: loaded (/etc/systemd/system/test.target)
	  Active: active since Thu, 22 Sep 2011 19:30:57 -0700; 3s ago


Expected results:
test.service fails, test.target remains inactive

Comment 1 Lennart Poettering 2011-09-23 03:12:53 UTC
You have no ordering between your two units, that means that test.target will be reached at the same times as test.service is already running. And if it is reached, then that's all that matters.

If you want to make sure that test.target doesn't get activated if test.service failed, then you need to make sure that test.target is activated only after the result of test.service is clear. Hence: add an After=test.service in addition to Requires=test.service to test.target.

In systemd requirement and ordering dependencies are fully orthogonal. THis is something to be aware of when writing manual dependencies. THis is mentioned a couple of times in the documentation.

(Side note: if you want test.target to go down when test.service fails later on you need to use BindTo= instead of of Requires=. The latter only matters at start-up of two units, the latter synchronizes both startup and shutdown of one unit to another).

Anyway, closing, since I am assuming there is no actual bug here and everything works as intended and documented. Feel free to reopen, if I missed anything.

Comment 2 Garrett Holmstrom 2011-09-23 04:51:56 UTC
(In reply to comment #1)
> If you want to make sure that test.target doesn't get activated if test.service
> failed, then you need to make sure that test.target is activated only after the
> result of test.service is clear. Hence: add an After=test.service in addition
> to Requires=test.service to test.target.

At first glance it appears as if Requires= implies After= for the case of oneshot services, because not doing so would violate the guarantees that Requires= directives provide.  The lack of After= in my example was due to this line of thought.  But after thinking about it some more I believe I can explain why it doesn't.  If I am wrong then please correct me.  If I am right then future readers will hopefully learn something.  :)

A oneshot service differs from a simple service in that systemd waits for the program to return before activating units that depend on it, but it does so only with respect to *order*, not status.  So during the short moment in which the /bin/false is running but has not yet returned in failure, test.service is still active, so test.target is free to activate as well.  Adding After=test.service makes test.target wait until /bin/false has returned with a definitive exit code (again, because it is a oneshot service) with respect to test.service's *status* before it can know whether or not it can activate.

Comment 3 Garrett Holmstrom 2011-09-23 06:34:11 UTC
Why does the original example behave differently than this one?

foo.service:
    [Unit]
    Description=Foo

    [Service]
    Type=oneshot
    ExecStart=/bin/false

bar.service:
    [Unit]
    Description=Bar
    Requires=foo.service

    [Service]
    Type=oneshot
    ExecStart=/bin/true

systemctl start bar.service

systemctl status foo.service bar.service:
    foo.service - Foo
    Loaded: loaded (/etc/systemd/system/foo.service; static)
    Active: failed since Fri, 23 Sep 2011 13:02:55 +0800; 1min 6s ago
    Process: 667 ExecStart=/bin/false (code=exited, status=1/FAILURE)
    CGroup: name=systemd:/system/foo.service
     
    bar.service - Bar
    Loaded: loaded (/etc/systemd/system/bar.service; static)
    Active: inactive (dead)
    CGroup: name=systemd:/system/bar.service

Sorry for all this continued activity.

Comment 4 Garrett Holmstrom 2011-09-24 23:57:42 UTC
It turns out that this actually is a bug [1], which was fixed in upstream commit a65cb51f [2] shortly before the release of version 36.  Re-proposing for F15 so we can get a backport...

[1] http://lists.freedesktop.org/archives/systemd-devel/2011-September/003478.html
[2] http://cgit.freedesktop.org/systemd/commit/?id=a65cb51f29ee177f6f800c87232b68475216a418

Comment 5 Michal Schmidt 2011-09-25 16:04:21 UTC
I had to revert the commit in systemd-36-3.fc16 because it caused a regression (bug 741078). We cannot push the commit to Fedora until bug 741115 is fixed.
And there may be other similar bugs, so we need to be careful if we backport it to F15.

Comment 6 Fedora Admin XMLRPC Client 2011-10-20 16:29:45 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 7 Fedora Update System 2012-01-11 15:01:01 UTC
systemd-37-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/systemd-37-6.fc16

Comment 8 Fedora Update System 2012-01-11 20:57:11 UTC
Package systemd-37-6.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-37-6.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-6.fc16
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2012-01-16 02:24:45 UTC
Package systemd-37-7.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-37-7.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-7.fc16
then log in and leave karma (feedback).

Comment 10 Fedora Update System 2012-01-17 20:22:33 UTC
Package systemd-37-8.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-37-8.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-8.fc16
then log in and leave karma (feedback).

Comment 11 Fedora Update System 2012-01-22 22:54:00 UTC
Package systemd-37-10.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-37-10.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-10.fc16
then log in and leave karma (feedback).

Comment 12 Fedora Update System 2012-01-26 22:57:46 UTC
Package systemd-37-11.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-37-11.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-11.fc16
then log in and leave karma (feedback).

Comment 13 Fedora Update System 2012-01-30 20:58:27 UTC
systemd-37-11.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.