On Thu, Oct 4, 2012 at 8:31 PM, Matthew Monaco <dgbaley27@0x01b.net> wrote:
Is there a general strategy as far as reusing /etc/conf.d/? A lot of units can use those as environment files to work as drop-in replacements for the rc.d scripts, but there's probably more systemd-ish ways of configuring most units.
The general strategy is "don't do that". The reason being that such a service file would never be acceptable upstream, as /etc/conf.d/ is arch-specific. This means that we will likely have to change it again in the future and it seems more natural to have the break now rather than at random times later. The ideal way to set things up is: don't use EnvironmentFile unless you must. If you can, set up the service file so that it can give a reasonable default out-of-the-box without further configuration. Moreover, prefer configurations to happen in the native config files of the service if they exist, rather than on the commandline. Lastly, the expectation should be that in case the user/admin needs to tweak the service file, this can be done by copying it to /etc/systemd/ and editing it there, rather than editing a config file. To be a bit less abstract: * An example of where I could see no way but use EnvironmentFile is for domainname.service in yp-tools. * An example of where one might argue that an EnvironmentFile would be useful, but where I think I found a reasonable way to avoid it is transmission-cli. Cheers, Tom