[arch-general] On /etc/conf.d deprecation
Hello list, 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. Imagine that in /usr unit file the daemon is being called as "binary -d". So I create the /etc unit file that supersedes it and calls it as "blah -d -n1". Then the package gets updated and the /usr unit file changes to "binary -d --lock=/whatever/path". As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called "binary -d --lock=/whatever/path $BLAH_ARGS" there would have been no such problem. /etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file. 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? Thanks in advance, Dimitris
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote:
Hello list,
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.
Imagine that in /usr unit file the daemon is being called as "binary -d". So I create the /etc unit file that supersedes it and calls it as "blah -d -n1". Then the package gets updated and the /usr unit file changes to "binary -d --lock=/whatever/path".
As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called "binary -d --lock=/whatever/path $BLAH_ARGS" there would have been no such problem.
/etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file.
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?
Thanks in advance, Dimitris
Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=. -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Sat, 8 Dec 2012, Curtis Shimamoto wrote:
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote:
Imagine that in /usr unit file the daemon is being called as "binary -d". So I create the /etc unit file that supersedes it and calls it as "blah -d -n1". Then the package gets updated and the /usr unit file changes to "binary -d --lock=/whatever/path".
As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called "binary -d --lock=/whatever/path $BLAH_ARGS" there would have been no such problem.
Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=.
Hi Curtis, I can't see how the .include directive would help in the case I mentioned. But even in other cases that it helps, I think it's a much more heavyweight solution to the problem, than the /etc/conf.d EnvironmentFile. What do you think? Dimitris
On 12/09/12 at 05:23pm, Dimitrios Apostolou wrote:
On Sat, 8 Dec 2012, Curtis Shimamoto wrote:
On 12/09/12 at 04:01am, Dimitrios Apostolou wrote:
Imagine that in /usr unit file the daemon is being called as "binary -d". So I create the /etc unit file that supersedes it and calls it as "blah -d -n1". Then the package gets updated and the /usr unit file changes to "binary -d --lock=/whatever/path".
As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called "binary -d --lock=/whatever/path $BLAH_ARGS" there would have been no such problem.
Keep some kind of configuration fine and use the .include feature of systemd units to source the config with EnvironmentFile=.
Hi Curtis, I can't see how the .include directive would help in the case I mentioned. But even in other cases that it helps, I think it's a much more heavyweight solution to the problem, than the /etc/conf.d EnvironmentFile. What do you think?
Dimitris
Yeah, I wrote back shortly after I sent that mentioning that it really wouldn't work, after I had thought it through a bit. I am not sure what you mean by heavyweight solution. If what you mean is that is will have to check for and then source a secondary file of the same name, I really don't think this would matter as it only has to do it once. Also, this seems like it is probably nearly the same amount of work for the system as sourcing a configuration file. Could you explain what you mean by heavyweight? I do agree with the fact that things should move towards following upstream, and the use of conf.d specifically should be deprecated. That doesn't necessarily mean that I think that you, the user, should not be able to create a config file on your own to source and use in the service. Personally, I have only made use of the .include feature once, and for something very simple. This issue of yours has made me think that it might be neat if there was a service variable to append to the ExecStart line. Thus making the .include feature more robust, as you could add to instead of replacing the actual command. -- Curtis Shimamoto sugar.and.scruffy@gmail.com
On Sun, Dec 09, 2012 at 04:01:08AM +0200, Dimitrios Apostolou wrote:
Hello list,
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.
Imagine that in /usr unit file the daemon is being called as "binary -d". So I create the /etc unit file that supersedes it and calls it as "blah -d -n1". Then the package gets updated and the /usr unit file changes to "binary -d --lock=/whatever/path".
As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called "binary -d --lock=/whatever/path $BLAH_ARGS" there would have been no such problem.
/etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file.
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?
Thanks in advance, Dimitris
Every time I update I just check systemd-delta if a package I have changed updates. -- Daniel Wallace Archlinux Trusted User (gtmanfred) Georgia Institute of Technology
Dimitrios Apostolou wrote:
Hello list,
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.
Imagine that in /usr unit file the daemon is being called as "binary -d". So I create the /etc unit file that supersedes it and calls it as "blah -d -n1". Then the package gets updated and the /usr unit file changes to "binary -d --lock=/whatever/path".
As you can see I won't get the update because I've overriden the unit file, I won't get any warning either, but if the original unit file called "binary -d --lock=/whatever/path $BLAH_ARGS" there would have been no such problem.
/etc/conf.d is a weaker but more elegant mechanism. I'm not saying it should replace unit files, but it should work *with* unit files, as the Arch way even if not in Freedesktop's - Fedora's recommendations. Of course anyone will still be free to copy and customize the unit file.
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?
Note that this is not an isolated request. At least FS#32354, FS#32336 and FS#32275 report the same for different packages. Note also that the systemd devs have stated that although the right way(tm) would be for all daemons to take their parameters from some config file of their own, using EnvironmentFile is an acceptable workaround for daemons that still take parameters from the command line. See: http://0pointer.de/blog/projects/on-etc-sysinit.html Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
The issue with /etc/conf.d is that it's Arch-specific. There are still a lot of cases where the packages themselves still provide the units, but there is a push to get them upstream whenever possible to remove a lot of burden from the packagers, and share more work between distributions.
Daniel Micay wrote:
The issue with /etc/conf.d is that it's Arch-specific. There are still a lot of cases where the packages themselves still provide the units, but there is a push to get them upstream whenever possible to remove a lot of burden from the packagers, and share more work between distributions.
Well, once the unit is upstreamed, the /etc/conf.d/foo file gets renamed to foo.pacsave and the onus of providing a way to specify the options falls to upstream. But for the time being, we need a solution for the units that are provided in Arch packages. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
Hi Dimitrios, On Sun, Dec 9, 2012 at 2:01 AM, Dimitrios Apostolou <jimis@gmx.net> 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
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
On Mon, Dec 10, 2012 at 12:46 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:
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.
So far this has not been necessary (afaik) for the projects that do provide unit files upstream. Of course, there are still a lot of projects that don't, so we will see what happens in the future.
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.
This seems like a typical example of something that the daemon itself should have support for reading from its own config files rather than relying on it being passed on the command-line. Rather than fixing this in Arch, I'd suggest contacting spamassassin and request support for these options (and any other) to be added to their config file. In the meantime I suggest patching the unit file locally, and revisit the issue if upstream reject the change.
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.
It appears sysstat store their configuration file in /etc/conf.d, so this is not really a problem. -t
Tom Gundersen wrote:
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.
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.
Conceptually, you are right. Unfortunately not all applications work that way today, so we need a way to pass the options to the applications that don't.
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 ...
* most packages have their own configuration file [...], 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.
From time to time, a package update requires changes to the configuration. This would only be one more such time. Moreover, the problem is the same once someone has customized the unit file. OTOH the /etc/conf.d file could be marked as a config file in the package and therefore go through the pacnew/pacsave mechanism on updates. Today, most Arch users are used to checking for pacnew/pacsave files regularly so they would spot the change as soon as the /etc/conf.d file got removed from the package and a .pacsave appeared in its place. Jerome -- mailto:jeberger@free.fr http://jeberger.free.fr Jabber: jeberger@jabber.fr
[2012-12-10 09:14:49 +0100] "Jérôme M. Berger":
Tom Gundersen wrote:
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.
Conceptually, you are right. Unfortunately not all applications work that way today, so we need a way to pass the options to the applications that don't.
Tomorrow is the new today: "The first option should always be to petition upstream to add their own config files with the required options." (Tom, in the exact same message you were replying to) In other words /etc/conf.d/ is the last resort; if we keep relying on it, nothing clean will ever get done. -- Gaetan
On Mon, 10 Dec 2012 20:27:38 +1100 Gaetan Bisson <bisson@archlinux.org> wrote:
[2012-12-10 09:14:49 +0100] "Jérôme M. Berger":
Tom Gundersen wrote:
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.
Conceptually, you are right. Unfortunately not all applications work that way today, so we need a way to pass the options to the applications that don't.
Tomorrow is the new today: "The first option should always be to petition upstream to add their own config files with the required options." (Tom, in the exact same message you were replying to)
In other words /etc/conf.d/ is the last resort; if we keep relying on it, nothing clean will ever get done.
Do I understand correctly that the plan is to remove conf.d entries together with corresponding rc.d scrtipts? Thanks, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Hi, Am 11.12.2012 17:15, schrieb Leonid Isaev:
Do I understand correctly that the plan is to remove conf.d entries together with corresponding rc.d scrtipts?
You seem to have missed the transition to systemd, see [1]. conf.d will be removed on a step-by-step basis in next couple of weeks/months. Best regards, Karol Babioch [1] https://www.archlinux.org/news/end-of-initscripts-support/
On Tue, 11 Dec 2012 17:22:49 +0100 Karol Babioch <karol@babioch.de> wrote:
Hi,
Am 11.12.2012 17:15, schrieb Leonid Isaev:
Do I understand correctly that the plan is to remove conf.d entries together with corresponding rc.d scrtipts?
You seem to have missed the transition to systemd, see [1]. conf.d will be removed on a step-by-step basis in next couple of weeks/months.
I haven't, for me it happened a long time ago. The reason to ask was to make sure that I can remove conf.d/ file from my locally-built packages, as the whole directory apparently goes away.
Best regards, Karol Babioch
[1] https://www.archlinux.org/news/end-of-initscripts-support/
-- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
participants (9)
-
"Jérôme M. Berger"
-
Curtis Shimamoto
-
Daniel Micay
-
Daniel Wallace
-
Dimitrios Apostolou
-
Gaetan Bisson
-
Karol Babioch
-
Leonid Isaev
-
Tom Gundersen