Hi Dimitrios, On Sun, Dec 9, 2012 at 2:01 AM, Dimitrios Apostolou <jimis@xxxxxxx> wrote: > from a reply I got to a bug report (FS#32817, reply is private) I found out > that configuration files in /etc/conf.d are deprecated and that the > supported way is to replicate and customize service files. [...] > So I'm curious to know why this mechanism was deprecated? Is it speed we > gain by not including the EnvironmentFile directive in the systemd unit > file? Is there some other reason I might be missing? 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. 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. * 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. Cheers, Tom
