[arch-general] On /etc/conf.d deprecation
jimis at gmx.net
Sun Dec 9 19:46:37 EST 2012
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
> 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
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.
More information about the arch-general