Bug 1198376
| Summary: | systemd documentation does not describe edge cases in unit file overrides | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | William Brown <william> |
| Component: | systemd | Assignee: | systemd-maint |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | lnykryn, systemd-maint-list |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-06-11 13:20:16 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: | |||
This is expected behavior. Changing ExecStart is really huge change for the whole service, so in that case you are supposed to write a new unit file to /etc/ So maybe this should be a bug in documentation then, that the behaviour as described is not as what is implemented. This edge case should be explicitly listed in systemd.unit or systemd.service man page (Actually, I think as a whole, partial unit files seem to be omitted from all documentation) I was wrong, ExecStart is a list option, so you have to reset it first. It is documented in systemd.unit. So I don't think that there is anything to fix here. |
Description of problem: Using a systemd demo file such as: /usr/lib/systemd/system/false.service [Unit] Description=Service that will always fail to start After=network.target [Service] Type=oneshot ExecStart=/usr/bin/false [Install] WantedBy=multi-user.target This will, as expected, fail to start. systemctl start false Job for false.service failed. See 'systemctl status false.service' and 'journalctl -xn' for details. Now we make an override that appears as: /etc/systemd/system/false.service.d/exec.conf [Service] ExecStart=/usr/bin/echo "That's better" We do a daemon reload, and a systemctl status, we see: Loaded: loaded (/usr/lib/systemd/system/false.service; disabled) Drop-In: /etc/systemd/system/false.service.d └─exec.conf We can see that the drop in has been loaded. Now we attempt to use it: Job for false.service failed. See 'systemctl status false.service' and 'journalctl -xn' for details. Process: 12404 ExecStart=/usr/bin/false (code=exited, status=1/FAILURE) In other words, the contents of the override, are not overriding the contents of the /usr unit file. If we remove ExecStart from /usr/lib/systemd/system/false.service, systemd correctly uses the value from the drop in: Loaded: loaded (/usr/lib/systemd/system/false.service; disabled) Drop-In: /etc/systemd/system/false.service.d └─exec.conf ... echo[12847]: That's better In summary. If a value exists in a drop in and the main unit file, the drop in value is ignored. The expected behaviour is that the drop in file should take precedence over the system provided file. Version-Release number of selected component (if applicable): systemd-208-11.el7.x86_64 How reproducible: Always