On Mon, Mar 14, 2011 at 12:53 PM, Tom Gundersen <teg@jklm.no> wrote:
Hi Thomas,
On Mon, Mar 14, 2011 at 7:07 PM, Thomas S Hatch <thatch45@gmail.com> wrote:
I think that the unfolding systemd issues here and the fact that we may be required to move to systemd might rewrite this problem altogether, in which case systemd would translate ordering and the order of services as they are placed in the daemons array may be irrelevant.
I will do some more research.
I don't think there are any immediate plans to move Arch to systemd, systemd might soon move to [community] though. However, if you are interested in knowing more about how systemd works on Arch, let me know as I'd be happy to help.
There is a wiki here: <http://wiki.archlinux.org/index.php/Systemd>.
I'd like to point out one thing which might not be obvious at first glance:
systemd has support for the DAEMONS array in rc.conf (partially written by me). However, when this is used, it might happen that systemd will not know the required ordering of daemons, in which case it will fall back to using the order from the DAEMONS array (so if this is incorrect you might get trouble).
To be more specific: when systemd has a native service file for a daemon, this will allow it to figure out the dependencies by itself and the position of the service in the DAEMONS array is ignored. If it does not have the service file for a given daemon, it will generate a default one, i.e. it will assume the ordering of the DAEMONS array is correct and order the daemon after the previous non-background daemon in the array.
All of this can be avoided by not relying on the DAEMONS array at all, but just adding generic systemd support to Puppet (if it is not there already), and then adding the needed service files to our systemd-arch-units package (the latter is very easy, and I'd be happy to help).
Cheers,
Tom
Thanks Tom, this helps a lot. And after talking to some of the Arch developers it seems that while systemd is going to most likely be moved into community at some point, that there are no immediate plans to move it into the default setup. This sounds like the normal Arch Linux approach, keep the core clean and small, yet support as much as possible. I think that it would be foolish to set up puppet to require a systemd configured setup, since it is clear that even if Arch does move to systemd, Arch will still load daemons via the DAEMONS array in the rc.conf. Therefore I think that what I am going to recommend to puppet labs and help implement, is that the services which are enabled by puppet be appended to the end of the DAEMONS array, and that they should always be after any services which are explicitly required by other puppet configs. This way we can maintain a system which is compatible with the base install of Arch without adding deps, and we don't require any changes to the runlevel. This approach should also continue to facilitate the capability of an Arch system admin to explicitly define the order in which daemons are started via puppet require statements. I am also going to request that puppet allow another feature, that a service can be slated as "start in background" which would not start the service in the background when puppet itself starts the service, but would only add the @ symbol in front of the daemon name in the DAEMONS array. Please let me know what your opinions are here, I will be discussing the viability of these recommendations in the puppet feature request ticket. https://projects.puppetlabs.com/issues/6697 -Thomas S Hatch -Arch Linux Trusted User