Bug 740703
Summary: | Target does not fail when a Required service fails | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Garrett Holmstrom <gholms> |
Component: | systemd | Assignee: | systemd-maint |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 15 | CC: | 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: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 741115 | ||
Bug Blocks: |
Description
Garrett Holmstrom
2011-09-23 02:39:04 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. (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. 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. 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 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. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. systemd-37-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-37-6.fc16 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). 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). 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). 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). 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). 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. |