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

[Lennart Poettering]

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

> Am 2015-01-23 14:27, schrieb Lennart Poettering:
> >>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..."
> 
> Oh, I didn't see that while skimming the man page. Still, I think a
> tutorial manpage as I described (different ways to override distro
> configuration) would be a good idea. Would you accept a patch for
> something like that? If so, what should the man page be called?

Sure, we can always use more man pages! Maybe simply call it
"systemd.turorial" or so, which could then get sections explainaining
how to best write new unit files, how to override/extend vendor unit
files, and so on.

> >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...
> 
> But if I want to add something to After=/Before=/..., I can easily do
> that with a drop-in just containing After=foo.service. And that's indeed
> very useful, I've used that a couple of times. So for symmetry reasons,
> I think the converse would also be quite useful (although I haven't
> needed it that often). I don't have a good idea for the syntax just now,
> but would you be opposed to at least adding 'design a syntax for this'
> to the TODO list?

It's not just the syntax I am concerned about. It's more about
overloading the language with too many features. It's supposed to be
easy to parse, just a bunch of assigments. In fact the assignment of
the empty string to reset lists is already a bit in the territory of
"this might be too complex"...

Lennart

-- 
Lennart Poettering, Red Hat