Bug 1198376 - systemd documentation does not describe edge cases in unit file overrides
Summary: systemd documentation does not describe edge cases in unit file overrides
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-03-03 22:56 UTC by William Brown
Modified: 2015-06-11 13:20 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-11 13:20:16 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description William Brown 2015-03-03 22:56:35 UTC
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

Comment 2 Lukáš Nykrýn 2015-03-04 09:37:09 UTC
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/

Comment 3 William Brown 2015-03-12 12:54:32 UTC
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)

Comment 5 Lukáš Nykrýn 2015-06-11 13:20:16 UTC
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.


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