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.
I like systemd, moved from Arch initscripts long time ago, yes it is a bit strange init system, but for me it is faster the Arch default initscripts. My boot time is exactly witch this from Arch initscripts, but I have 2x more deamons as previous.
I really don’t understand the anti-systemd position. Faster + Not Bash = Better, right? My theory is that these people are either drinking too much of the anti-Lennart kool-aid, or have never actually written an init script.
Faster+ Not Bash != Better. There are two important things: Stability and Choice (that’s the important benefit of Linux). Also, systemd may not suit slow machines, having many daemons in memory.
“Also, systemd may not suit slow machines, having many daemons in memory.”
Well, except that embedded developers were among the first to jump on the systemd bandwagen: http://www.youtube.com/watch?v=aVcfjs02Srs
While I think you’re being somewhat passive-aggressive, your post is rather useful. This whole systemd mess is starting to read like one big cautionary tale. Beware of idiots working for Red Hat, for a single such obnoxious moron can fuck up the wider Linux software ecosystem. I’m still using Arch, because Arch still works, but a few tests of systemd have shown it fails with such minor stuff as running daemons. Therefore I am immensely glad to see ArchBang is not going to participate in the crazy. Though I never imagined it was going to be more Arch than Arch one day. Anyway, thanks for the post. It’s made me realize that there are still feasible possibilities.
” but a few tests of systemd have shown it fails with such minor stuff as running daemons”
Care to explain?
Hi don’t play naive, it was never about “just booting the system” it was always about reinventing Unix and making sysadmins job miserable in the process. Suddenly your init system wants to replace your syslog with some binary abomination, suddenly your system administrator who has to support hundreads of third party commercial software is not supposed to write init scripts?
I will settle for systemd booting my Arch system and stopping right there – do not start an ssh agent, do not start a consolekit daemon, do not mess with my syslog – any day of the week.
Hi all of your options above have not only been explored but some proved and some discounted, udev-fork is moving towards full sysd api compatibility https://bitbucket.org/braindamaged/udev/changeset/a40c0b83ba7b7f9c31f28c8ac30efdffa0f6c22f at source, the soname change is only the start they are a clever bunch of people and working with gentoo on this, the patch was just because i asked for it, dont blame him for it, he has taken enough stick for it already, if someone is braindead then thats me. Btw we have a working proved version of arch without sysd now, the only problem is device-mapper complains but still functions, that is just with the soname change, but since lvm2-lsd is last to be build on changeover, it links fully to libudev and obviously works perfect. Even so i am a perfectionist, all the “affected” ie linked to udev packages, will be rebuilt against udev-fork and presented on a custom repo just in case :), its an automated build so will always track arch packages.
Every affected service ( like syslog-ng which fails without sysd ) will be recompiled without sysd compile options and installs, and when udev disappears as a name all the relevant packages will have deps point back to udev
Currently we are using 2012.5 initscripts which rather surprisingly work faster and better then later versions, We have gone beyond runit, we cannot contact the author so have to assume to he is awall, which is not good for a real credible alternative, but a init author has turned up to create either a brand new init or continue the work on runit at src level.
Tried LFS build, here is an experemental pkgbuild if you fancy a laugh
# $Id: PKGBUILD 159356 2012-05-22 12:46:15Z tomegun $
pkgname=udev
pkgver=189
pkgrel=1
pkgdesc=”The userspace dev tools (udev)”
depends=(‘util-linux’ ‘glib2’ ‘kmod’ ‘hwids’ ‘bash’ ‘acl’)
provides=(‘systemd-tools’)
replaces=(‘systemd-tools’)
conflicts=(‘systemd-tools’)
install=udev.install
arch=(i686 x86_64)
license=(‘GPL’)
makedepends=(‘gobject-introspection’ ‘gperf’ ‘libxslt’)
source=(“http://www.freedesktop.org/software/$pkgname/$pkgname-$pkgver.tar.xz”
“http://anduin.linuxfromscratch.org/sources/other/udev-lfs-189.tar.bz2”
initcpio-hooks-udev
initcpio-install-udev)
backup=(etc/udev/udev.conf)
groups=(‘base’)
options=(!makeflags !libtool)
md5sums=(‘ac2eb313f5dce79622f60aac56bca66d’
‘2840CD8C5FA91617EFD36123486A7AC5’
‘e433c11d38cf4f877b41d06e2753ebe0’
‘e6faf4c3fe456f10d8efd2487d5e3cb7’)
build() {
cd $srcdir/$pkgname-$pkgver
cp -pr udev-lfs-189 /systemd-189/
./configure –prefix=/usr
–sysconfdir=/etc
–libexecdir=/usr/lib
–with-firmware-path=/usr/lib/firmware/updates:/lib/firmware/updates:/usr/lib/firmware:/lib/firmware
–with-usb-ids-path=/usr/share/hwdata/usb.ids
–with-pci-ids-path=/usr/share/hwdata/pci.ids
make -f udev-lfs-189/Makefile.lfs
}
package() {
cd $srcdir/$pkgname-$pkgver
make -f DESTDIR=${pkgdir} install udev-lfs-189/Makefile.lfs install
# install the mkinitpcio hook
install -D -m644 ../initcpio-hooks-udev ${pkgdir}/usr/lib/initcpio/hooks/udev
install -D -m644 ../initcpio-install-udev ${pkgdir}/usr/lib/initcpio/install/udev
# udevd moved, symlink to make life easy for restarting udevd manually
ln -s ../lib/udev/udevd ${pkgdir}/usr/bin/udevd
# the path to udevadm is hardcoded in some places
install -d ${pkgdir}/sbin
ln -s ../usr/bin/udevadm ${pkgdir}/sbin/udevadm
# fix wrong path to /bin/sh
sed -i -e ‘s#/usr/bin/sh#/bin/sh#g’ $pkgdir/usr/lib/udev/keyboard-force-release.sh
# Replace dialout/tape/cdrom group in rules with uucp/storage/optical group
for i in $pkgdir/usr/lib/udev/rules.d/*.rules; do
sed -i -e ‘s#GROUP=”dialout”#GROUP=”uucp”#g;
s#GROUP=”tape”#GROUP=”storage”#g;
s#GROUP=”cdrom”#GROUP=”optical”#g’ $i
done
}
its good but way to LFS specific without heavy modding of the LFS makefile, but works for mucking around with, turns out it performs just like udev-for, which figures since it is effectively udev-fork but achieved another way, dev-mapper still complains but works if not recompiled
i would love it to be tru that sysd did nothing just sitting there as a binary, but if you look at the thread on the matter https://bbs.archlinux.org/viewtopic.php?id=148429 i pleaded for someone to tell me ( with proof ) that was the case, unfortunately as i suspected not one word was said, that speaks volumes, without doubt its up to shit loads when “just sitting there” , in dbus, pam, ext4 journal, god knows where else, and thats why i started all of this, im not insane 🙂 if there was no reason to go through all of this why would any sane person bother.
Anyway i would like to invite mr McRae onbord to this project , im sure his skills would be of great benefit to helping us get this right and not fall into any pitholes of the past
Thank you
Jubei
Regarding proof of whether systemd binaries do nothing when not booting using systemd – you also had no replies that they actually do anything when not using systemd. So you are essentially creating a lot of work for yourself with no evidence of any benefit – I’d call that insane! 😛
I’m surprised at the exclusion of runit due to being unable to contact the author… Especially given the runit web pages says to only contact him via the project’s mailing list and there are no emails regarding this there.
Finally, I will not be joining this effort. I am quite happy with systemd so far and have higher priority areas of Arch Linux to improve.
Oh 🙂 actually had no idea it was you from the forums 🙂 hiya mate, hows the weather in oz ( know the answer to that you lucky b***** ) Greetings from the Austiran alps ( am on holiday) , Thanks for the heads up about the runit author ( and the other poster ), that is extremely cool, as you can tell am new at this, and dont tend to use the “standard” forms of communication frequented by coders. I have plans for runit 🙂 quite extensive plans, that need an author, so thanks again.
I know you havent got the time but could you keep you critical eye on us please ? And pipe up if you think we are going in the wrong direction. I cant speak for the other project members but i value your advice and input.
Yep no one stated that it WAS doing something, but studying the Fedora lists on it ( when they were originally configuring the thing, sorry cant get to a link for you ) the interactions are so complex that to tell truth they wernt even sure, to prove it one way or another seem a computer science nightmare and way beyond me. So yes suppose in some respects am taking a gamble, it COULD be pointless, but what about the future? The future sees systemd adoption, and then the question of weather its doing nothing is pointless, cos it will be doing something 🙂 So yes even if taking gamble now, no gamble in a few months 🙂
Anyway im back on my bike seeees ya!
The proper way to contact the author of runit is through the supervision m-l.
http://www.skarnet.org/lists/
s6 uses the same list for discussion and announcements.
Butthurt?
hope you’r not mistaking politeness for butt-kissing 🙂
Make no bones about it, there will be a systemd free arch available, all 150+ packages will be provided, and tracked via git ( properly ), there will be a build-bot for the task etc.. and udev-fork is pretty key to all of this, thank you ( no not kissing your butt either 🙂 )
Giving mr McRae an opportunity to help seemed reasonable, and his refusal seems reasonable to me :),
But hey im looking for talented c/c++ coders you interested in something a bit special? maybe something with a bit of cash at the end of the rainbow?
>there will be a systemd free arch available
i switched to gentoo not so long ago, and systemd was not the only reason for that (in fact, it was before systemd was pushed in arch).
>im looking for talented c/c++ coders
contact me via mail (you can find it e.g. in udev git logs).
Hello, Allan.
Mostly I see Your powerful argumnt is simplicity. And it’s really good when it’s brought for users! But I can’t get on how could installer removal make the installation process simpler. That is the question one.
And though there are different oppinions about /lib symlinking, though not a secret for everyone that /usr/lib life started because of hardware limitation issues (because of simplicity of solution, BTW), nowadays it came to obtain some semantic meaning, e.g. /bin and /lib are the directories, which used to be loaded first of all. So, if /usr fails for some reason, we are always to get machine work with fallback root directories…..Ah, wait, I remembered, there is ‘local’ directory for it! Yeah, now I see… But if so, why wouldn’t they to be symlinked to some /local/* ? This should be a real simplicity improvement, i think!
At last, my main question, because it IS now a real problem for me! Among all that progress You try to gain through slight simplifications, getting on thoughts about i686 deprecation, I never saw nothing to be done for x32 integration! It’s already half a year passed after 3.4 release! However it is a real performance gain to use this ABI. Meanwhile You enraged by that moot simplicities, what’s about this one real x8-64 users gain? Should we hope to see it at all?
Pray for answers.
Allan, as always, great post!
Personal rant:
My god, how long people will be wining about systemd in Arch?! It’ll happen, period. Core/Dev team decided it’s the best move for Arch so get over it or change distro (or go against the flow and make other init work for you). Moreover I think (based on many forums posts) that whole confusion is made by very few users who are to stubborn and short-sighted* to switch. There is a lot of happy systemd users out there. It’s rolling-release people, things change – roll with them! Or put Debian on your hardware and postpone systemd for couple years (but you can’t run away forever, if not systemd then something else will change – that’s how technology works)
* there is very few people for whom systemd simple doesn’t fit. Majority is just wining because systemd is different.
PS We need T-shirts with Arch logo and “In devs we trust” sentence on them 😉
Bored with all the talk of systemd, I have been using it for a while now without a problem. Forgive me if I have not had time to update build scripts and installer to run systemd, Arch does change daily and depending on which way the wind is blowing a new config appears.
Mr Green
ArchBang Developer
I like systemd. I’ve managed to remove slim, consolekit, syslog-ng, oblogout and am looking forward to removing more, (dbus, polkit, udisks(2), possibly)? The less I have to install and configure the more I like it. Let systemd handle it all.