Tom, thank you very much for the extensive reply, I've been searching a
lot for the reasoning you explained.
On Sun, 9 Dec 2012, Tom Gundersen wrote:
Speed is not a concern.
The way things should ideally work, IMHO, is:
Options related to the init-system, such as where the lock-file is
located should be indicated as an option in ExecStart. The reason this
makes sense is that it must match what is specifid in PIDFile=. The
same goes for any other option that systemd requires to be a certain
value to function correctly. All these options are things that the
admin would not usually change.
Agreed, as I pointed in my example such options should be hardcoded in
ExecStart. Unfortunately this comes with the side-effect of missing any
updates if ExecStart gets customised in custom unit file (I didn't know
about systemd-delta, thanks to everyone who mentioned it).
However, options that are unrelated to the init-system should not be
specified in ExecStart=, but should be configured in the applications
own configuration file. It has nothing to do with systemd, so for
systemd to just stupidly read it from one location and pass it on to
the program without touching it seems wrong on a conceptual level.
More concretely, why we should avoid /etc/conf.d (and why all distros
should discourage similar use of their own config directories):
* it is distro-specific, so once we switch to unit files provided by
upstream, we would have to change the location of the configuration
file to whatever is used upstream (maybe the Debain location, or maybe
the Fedora one, or maybe something else, it would probably differ from
package to package). I think it is better to have a general rule
saying "we don't use /etc/conf.d with systemd", than package by
package moving their config files around as things are upstreamed.
Personally I believe all distros that switch to systemd will add their own
twist to it. Distro-independant Unit files sounds like Utopia. In reality
I expect unit files to be patched for various custom needs of different
distros. But anyway if it is actually achieved it would be great.
* most packages have their own configuration file where some, if not
all, options can be configured. Having two locations for configuring
the same options is not ideal, so we want to avoid that to the extent
possible. One could imagine using /etc/conf.d for packages where not
all command-line options can be configured in the config file.
However, what do we then do when one day the config files are extended
to deal with all the options? If we drop /etc/conf.d support we'll
have the same problems as above: package by package changing
behaviour.
There are cases when using /etc/conf.d is necessary, but to the extent
possible we should try to avoid it. Moreover, the first option should
always be to petition upstream to add their own config files with the
required options, and only if that is impossible add /etc/conf.d
support.
Just let me be specific with two examples that I use /etc/conf.d, and it
may be more clear why they are still needed:
1) On a memory constrained system I use the following for spamassassin:
SPAMD_OPTS="-c --min-spare 0 --max-children 1 -s local5". I don't think
this can be customized by other means.
2) For the crond started service of sysstat, I keep all history with
HISTORY=9999 in /etc/conf.d/sysstat. I don't know if /etc/conf.d is being
deprecated for everything or only for systemd started daemons, but this is
a non-systemd example that makes good use of it.
Thanks,
Dimitris
Cheers,
Tom
