For those who came here looking for the solution to the systemd “problem” in Arch Linux, this is not the article you are looking for. I care very little about my init system beyond that it should successfully boot my computer and start the software I need it to start. In fact, my entire understanding of the boot process goes “Push button… *MAGIC* …prompt”, so taking advice from me on the boot-up process may not be the best idea…
However, what I do know about is the Arch Linux packaging system and how to put together a Linux distribution. So I am going to discuss how people would go about providing all the tools to run an init system that is not systemd in Arch Linux. Many lessons will be taken from how systemd was provided in Arch Linux; firstly as a community based projected and then as official packages providing a secondary init choice in the repos. From what I see from current efforts, people seem slightly naive about what is required and are completely ignoring what has gone previous.
Lets start with choice number one. Where are you going to get udev from? I see two choices here. Firstly, you could just create a package containing on the udev files from the systemd tarball. This is the approach used by Linux From Scratch and you could even use their Makefile. The original email announcing the merge of udev into systemd states that udev can still be built for usage outside of systemd systems and that will be supported officially. So I personally would choose that option. However, I know people are concerned that udev will become more fully dependent on systemd. Here is the email that people cite as the end on non-systemd udev. I read that as saying that genuine issues when using udev outside of systemd will be fixed. There is also nothing saying that patches for udev that do not impact its usage in systemd will not be applied. Anyway, for those people there is a fork of udev being developed. If you select this option, there are a couple of things to be aware of. Firstly, there is is no guarantee of compatibility with the udev from systemd so the libudev. In fact, the fork has a different soname and that means you will need to recompile all software that links to it (~30 packages in the Arch repos). Secondly, the development of this fork currently appears to be porting relevant commits from the systemd tree to a snapshot of the udev codebase before the merge happened. It will be of interest to see what happens as these code-bases diverge and whether any independent development (excluding the build system…) occurs in the fork. (See Edit #2 below)
Choice number two is what you are going to do with software that links to the various libsystemd-* libraries. The anti-systemd way is to rebuild all this software to not have this dependency. That is only 12 packages at the moment, although the number is growing… An approach requiring no rebuilding would to just provide a libsystemd package. These are just libraries on your system and most software that uses them has something like if(sd_booted()) in it. That results in these doing nothing when your system was not booted with systemd.
If providing separate packages for udev and libsystemd, you will need to be careful with the provides array in their PKGBUILDs so that you avoid unnecessary rebuilds. But speaking of unnecessary… Why provide separate packages for udev and libsystemd at all? Just have the systemd package installed. If you do not boot with systemd, then its binaries just sit around on your system doing nothing but take a whopping 10MB of space (that number is pure guesswork…). Call me lazy, but all that packaging seems a lot of effort. Do you repackage libjpeg-turbo to get rid of its binaries that you do not use?
Once you have managed to get that far, you will need to figure out which init system you will use and how you will manage services. I am going to state that the current Arch Linux initscripts are a dead end. The current version requires systemd binaries, so to avoid that you would need to grab an old release. Then you would have to fix the bugs that were fixed by moving to the use of systemd binaries. Finally, when Arch Linux moves to systemd by default, the service management scripts in /etc/rc.d will gradually be removed, which is no great loss as they are horrid anyway. I will also assume that some monitoring of services and restarting them when they fail is a worthwhile goal, as no-one really has spoken out against that. Completely ignoring upstart (because yuck…), you have two real options for this.
Option #1 is to use runit. This is a complete init system replacement with service management and seemed to be a popular choice among people with severe systemd allergies on the arch-general mailing list. As a bonus, the website has a whole heap of run scripts that you can use to provide a runit-arch-services package (analogous to the systemd-arch-units package that was provided in the early systemd days and is currently being phased out). Note that means you are going to have to provide an runit run file for every piece of software in the Arch repos if you are doing a proper job. If you are going to use runit, you may want to also consider the ignite project which provides additions to runit that allows it to use some old style /etc/rc.conf style configuration.
I am going to pretend that ignite‘s definition of “adapted from Arch initscripts” does not mean GPL copyrighted code was copy-pasted and released as public domain! (See Edit #1 below)
Option #2 is to use OpenRC, which is developed by people over at Gentoo. This works with your systems init, so you are going to need to keep sysvinit as well. Because it is compatible with the Gentoo init scripts, you will probably be able to find the daemon scripts you need in the Gentoo portage tree. I assume for a more “old school” Arch Linux experience, you would want to do something similar to ignite and pilfer relevant bits from the Arch Linux initscripts package. I believe on of the openrc developers posted to the arch-general mailing list suggest it was used, so there is probably help available getting this running for those that are interested.
That is a brief summary of what is required to purge your system of the “systemd virus” – for now. But as a virus, it will spread… Soon you will need to deal with a lack of ConsoleKit and if all the hysteria is to be believed, every single other piece of software on your system will soon be absorbed into systemd. So if you are going to do a lot of work to avoid systemd, be prepared for the amount of work to increase in the future. But do not concern yourself too much… Arch Bang has plans to save all the systemd haters! And they have made an installer so their ability to handle actual packaging of something this complex is not to be questioned!
Post publication edits:
Edit #1: I am removing my comment about the licensing of ignite for two reasons. 1) The author contacted me and pointed out the only directly copied bits was the mountpoint code (~4 lines). I see other similarities, but admittedly there is not many other ways to do [[ $foo ]] && ... style tests. 2) There is no license in the Arch Linux initscripts code base. It used to print “GPL2″ when booting, but that has even been removed.
Edit #2: Do you know how to fix the udev fork having a different soname for its library? Use this patch! Now I am convinced the author of the fork knows too little for it to be useful.