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