[systemd-devel] service.d/.conf files and multi-valued options

Lennart Poettering lennart at poettering.net
Fri Jan 23 05:27:41 PST 2015

On Fri, 23.01.15 14:15, Christian Seiler (christian at iwakd.de) wrote:

> Am 2015-01-23 12:21, schrieb Matthias Urlichs:
> >Igor Bukanov:
> >>It is not clear from the systemd.unit manual page what happens when
> >>foo.service.d/bar.conf sets an option like Service/ExecStartPre that
> >>can be specified multiple times. From experimenting I see that *.conf
> >>files supply additional values to the option and to overwrite or
> >>remove already given values for the option one have to copy the whole
> >>file into /etc and edit it there. Is it so?
> >
> >Doesn't the manpage state that an empty entry clears the list?
> Yes, it does, although only in the general systemd.unit(5), not in the
> specific options, so maybe it's not that easy to find.

Actually, it kinda says it in the specific options. From the
explanation of ExecStart=:

"...If the empty string is assigned to this option, the list of
commands to start is reset, prior assignments of this option will have
no effect..."

And at the explanation of ExecStartPre= says the syntax is identical
to ExecStart=. So I think we are covered here. I mean, we could
certainly duplicate the discussion of ExecStart= at ExecStartPre=, but
I think it's nicer to just reference it again.

> Btw. it would also be nice to have a possibility to just remove a
> specific entry from a list, not to reset it completely. Probably less
> for things like Exec*=, but more for After=/Before=/...
> For example, if there's a unit with After=b.service c.service und as
> an admin I want to not order it after c.service, I will have to first
> reset the list (empty After=) and then add all the current other
> units it orders after again. If an update then makes the unit also be
> ordered after d.service to fix some other bug, the local setting will
> override the After=d.service too...
> Maybe something like 'After-=c.service'? Although that would probably
> break traditional ini parsers trying to process unit files...

I'd be very careful with coming up with more and more syntaxes like
this. People have also requested "+=", to append things to existing

I think for simplicity's sake the right approach to remove parts of a
unit file is to copy it from /usr to /etc, and then modify it
there. .d/ is not the answer to everything. I am aware of course that
copying the files from /usr to /etc will also disconnect you from
new unit files added by package updates, but I guess you cannot have a
cake and eat it too...


Lennart Poettering, Red Hat

More information about the systemd-devel mailing list