Sunday, July 29, 2012

Migration to systemd on Arch

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 predictioning, 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 units 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
# pacman -Rns sysvinit initscripts
# pacman -S systemd systemd-sysvcompat systemd-arch-units
# echo `hostname` > /etc/hostname
In the file /etc/vconsole.conf write
KEYMAP=us
FONT=lat9w-16
FONT_MAP=8859-1_to_uni

and in the file /etc/locale.conf write

LANG=en_US.UTF-8
LC_COLLATE=C

and lastly in the file /etc/timezone enter your timezone, for example:

Asia/Calcutta

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
0
LOCAL
You should also uncomment the en_US-UTF8 UTF8 and en_US-ISO8859-1 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.
For example:

vboxdrv
vboxnetflt

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 over it:
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.

Example:
# 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
$ 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.

References:
https://wiki.archlinux.org/index.php/Systemd
http://0pointer.de/blog/projects/systemd.html
http://0pointer.de/blog/projects/why.html
http://freedesktop.org/wiki/Software/systemd
http://distrowatch.com/table.php?distribution=arch

Notes:
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.

Monday, July 2, 2012

Fix disfunctional shutdown/restart button in Arch Linux

Arch Linux is one awesomely awesome operating system! You get a chance to build your own Linux system from scratch, right from installing the kernel, then installing core-utils, followed by editing config files and then setting up X and a Desktop Environment. I will post sometime later an step by step verbose article on building a system with Arch + XFCE + General utilities. For now I'll focus on the title of this post.

Those of you who run Arch and start your GUI with:

exec ck-launch-session dbus-launch startxfce4

in xinitrc and use SLIM might have noticed that you can't shutdown with the buttons available in your Desktop Env.

The reason is that the updated version of SLIM already launches a console kit session(the thing responsible to execute commands that require root access). So there are two console kit sessions and the conflict.
You can check the number of console kit sessions yourself by:
ck-list-sessions
To solve it, remove the portion ck-launch-session dbus-launch from the exec line.
Here is my .xinitrc, that you may use.

#!/bin/sh
# ~/.xinitrc
# Executed by startx (run your window manager from here)
if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

DEFAULT_SESSION=startxfce4
case $1 in
  lxde)
  exec startlxde
  ;;
  xfce4)
  exec startxfce4
  ;;
  *)
  exec $DEFAULT_SESSION
  ;;
esac


/usr/bin/xscreensaver -no-splash &