Today I migrated to systemd on my Arch
system. All the mortals unaware of the word, please allow me the privilege to introduce systemd - the latest replacement PID 1 in your linux box. As you might be aware that after the kernel loads up, it launches init
in the inter-stellar space with the process ID of 1 which is responsible for forking other payloads into the user space. The traditional SysV Init
boot method was conceived decades ago and has been used almost unaltered in most of the linux distros. It was excogitated in the age when processors were babies with single cores which could compute ONLY a few million instructions a second, the computers had only crossed the stone age and had just stepped into the semiconductor age(the second part of this statement is technically wrong, take it just as a humorous piece). SysV Init
starts the userspace processes one by one. But today in the age of multicore monsters with each of the 4(or 6) cores capable of simultaneously computing at a staggering speed of more than a couple of billion instructions per second coupled with architectural innovations like simultaneous multithreading
(SMT i.e. hyper threading in intel terms), advance tournament branch prediction
ing, added with speculative execution
and deep pipelining that makes sure an application cleverly programmed can run almost as fast as the demarcation set by Amdahl's law
; Sys V init is very inefficient since it's coders hadn't dreamt of these features in their weirdest of day(night)dreams.
Then some bored lazy guy named Lennard Pottering
at Fedora fed up of waiting for the age old system boot process to load his OS had a mesmerizing realization of an Archimedes like enlightening idea - to boot a system fast, start less; and start more parallelly
. And he came up with systemd along with some helping hands in the community. Although Ubuntu gave up on SysV Init long ago and took the upstart
way, but systemd is any day any moment better than upstart.
systemd organises services and other things(beyond the scope of this post) into units
. An assortment of one or more unit
s can be grouped into a target, which is similar to the concept of runlevels
but is not exactly run level. A target can be a requirement for another target(i.e. latter inherits from former). And systemd starts the units as parallelly as possible by making sure independent units can start together and a unit dependent on another is held on, until its dependency is started.
Enough of background story and theory! Lets see how easy it is to set it up on Arch. Archwiki has an awesome page for it, but n00bs are n00bs and are born to make mistakes and do things that they are not supposed to. Even non-n00bs can make silly mistakes :P
Install the packages systemd, systemd-sysvcompat, systemd-arch-units after removing the packages sysvinit and initscripts. But before removing initscripts, you may want to take a backup of /etc/rc.conf. Afterwards you should make a few files which are expected by systemd. They are /etc/hostname, /etc/vconsole.conf, /etc/locale.conf, /etc/timezone
# cp /etc/rc.conf /etc/rc.conf.bak
In the file /etc/vconsole.conf write
# pacman -Rns sysvinit initscripts
# pacman -S systemd systemd-sysvcompat systemd-arch-units
# echo `hostname` > /etc/hostname
and in the file /etc/locale.conf write
and lastly in the file /etc/timezone enter your timezone, for example:
If you dual boot with Windows then to keep your linux system showing localtime write the following in /etc/adjtime
0.0 0.0 0.0
You should also uncomment the en_US-UTF8 UTF8
lines from /etc/locale-gen and then run the locale-gen
command on the terminal as root user to avoid locale warnings while next time an mkinitcpio
is done or something else that requires it.
If you load some modules at boot time by adding them in /etc/rc.conf
then to do the same with systemd, you can create a file named /etc/modules-load.d/modules.conf
and add all your modules names each in a single line.
If you run some services from /etc/rc.conf at boot time, then you can use:
# systemctl enable sshd.service
to keep starting them at boot. These service configs are in /usr/lib/systemd/system/
directory and are the units as introduced somewhere above in this post. All the files with extension .service
are daemon units that you can run at boot or for certain targets, or later by the systemctl command.
In case of some services, for example networkmanager you will see an error if you try to do a systemctl enable
Failed to issue method call: No such file or directory
Don't panic. Just create a symlink in /etc/systemd/system for that file in multi-user.target wants.
# ln -s /usr/lib/systemd/system/networkmanager.service /etc/systemd/system/multi-user.target.wants/networkmanager.service
This may not exactly work in some cases if the daemon you want to start requires other daemons to be enabled too. In that case you can enable the required daemon first, or the required target first.
Hope, this should get you up and running with systemd on your arch box.
One more thing, systemd provides a nifty tool to analyse your boot time. Try these commands, and you will know what I mean:
$ systemd-analyze blame | less
$ systemd-analyze plot > ~/bootplot.svg
By the way my Fujitsu Siemens Amilo Si3655 with Core2Duo P8400 2.26GHz, 320GB hard disk, 4 gigs of RAM and pae kernel boots in less than 13 seconds. Here is my output from systemd-analyze.
Startup finished in 656ms (kernel) + 2521ms (initramfs) + 9648ms (userspace) = 12826ms
And here is my plot svg file
1. Commands prefixed with # are to be run as root user, and ones prefixed with $ are to be run as normal user.
2. If you are not an arch user, please don't try to install systemd by following this article word by word. Fedora and OpenSuse come with systemd by default. Other distro users should check corresponding wiki and forums.