How to migrate from initscripts to systemd on Archlinux

In this how to I will describe how to migrate from initscripts to the “new” systemd init system on Archlinux. Initscripts will still work, but it is recommended to switch completely to systemd.

1. Update and installation
2. Migration and configuration
3. Optional improvements
4. Useful commands
5. Troubleshooting

1. Update and installation

1. First do a full system update:

   $ sudo pacman -Syu

2. Install systemd-sysvcompat. Say yes when you are asked if sysvinit should be removed:

   $ sudo pacman -S systemd-sysvcompat
   

2. Migration and configuration

The goal of this section is to move the programs, daemons etc. defined in the DAEMONS list oft /etc/rc.conf to systemd.

1. First print the contents of rc.conf in the terminal:

   $ cat /etc/rc.conf

   The resulting output should look similar to this:

   #
   # /etc/rc.conf - configuration file for initscripts
   #
   # Most of rc.conf has been replaced by various other configuration
   # files. See archlinux(7) for details.
   #
   # For more details on rc.conf see rc.conf(5).
   #
   DAEMONS=(hwclock @syslog-ng !network @crond acpid dbus iptables wicd 
   ntpd avahi-daemon @cupsd)
   

   We need to remember what daemons, services, programs etc. are started at boot so we can enable them in systemd later. Write down the contents of the daemons array on a pice of paper or copy them into a new text file.

2. Now it’s time to find out how to enable the programs defined in the DAEMONS list of rc.conf in systemd. Luckily most of the programs come with preconfigured service-files for systemd. You can find them in the directory /usr/lib/systemd/system .

   $ cd /usr/lib/systemd/system
   $ ls | grep .service

   The output should look similar to this shortened example:

   acpid.service
   alsa-restore.service
   alsa-store.service
   autovt@.service -> getty@.service
   avahi-daemon.service
   avahi-dnsconfd.service
   ...

3. Find the service-files, which correspond to the names of the programs defined in the DAEMONS list of your rc.conf . You can also take a look at this wiki-page listing the names of important service-files: daemons-list . If you still can’t find the service-file for a program you can try to find it here: service-files . These are the service-files corresponding to the contents of the daemons list from 2.1) :

   acpid.service
   avahi-daemon.service
   cronie.service
   cups.service
   dbus.service
   iptables.service
   ntpd.service
   slim.service
   syslog-ng.service
   wicd.service

4. Enable the services you found for systemd by using the following command (its good to be in the directory, so you can use the tab-key to autocomplete the services names):

   $ sudo systemctl enable serviceName.service

   Example:

   $ sudo systemctl enable acpid.service

   Notice:
   If you try to enable debus.service, you will get the following output:
   

   $ sudo systemctl enable dbus.service
   The unit files have no [Install] section. 
   They are not meant to be enabled using systemctl.

   However this is ok, because systemd starts dbus by default.

5. Remove all programs, daemons etc. from your /etc/rc.conf that you enabled in systemd. Only leave the entrys for which you couldn’t find service-file . My rc.conf from 2.1) looks now like this:

   #
   # /etc/rc.conf - configuration file for initscr$
   #
   # Most of rc.conf has been replaced by various $
   # files. See archlinux(7) for details.
   #
   # For more details on rc.conf see rc.conf(5).
   #
   DAEMONS=(hwclock)
   

6. Check if the services you enabled before are actually enabled. Execute the following command to do so:

   $ systemctl list-unit-files

   Example output (the running services are labeled enabled or static):

   UNIT FILE STATE
   proc-sys-fs-binfmt_misc.automount static
   dev-hugepages.mount static
   dev-mqueue.mount static
   proc-sys-fs-binfmt_misc.mount static
   sys-fs-fuse-connections.mount static
   sys-kernel-config.mount static
   sys-kernel-debug.mount static
   tmp.mount static
   cups.path enabled
   systemd-ask-password-console.path static
   systemd-ask-password-wall.path static
   acpid.service enabled
   alsa-restore.service static
   alsa-store.service static
   autovt@.service disabled
   avahi-daemon.service enabled
   avahi-dnsconfd.service disabled
   colord.service static
   console-getty.service disabled
   console-kit-daemon.service disabled
   console-kit-log-system-restart.service static
   console-kit-log-system-start.service static
   console-kit-log-system-stop.service static
   console-shell.service disabled
   crond.service disabled
   

7. You’re done. Start to pray and reboot your system ;-). You may be able to improve your systems start-up time, by taking a look at the next section of this post and I also recommend to take a good look at the Useful commands section. If you run into any problems make shure to take a look at the troubleshooting section of this how to.

3. Optional improvements

• You can enable readahead for possible improved boot-time (needs some reboots to work well):

  $ sudo systemctl enable systemd-readahead-collect.service 
  $ sudo systemctl enable systemd-readahead-replay.service
  

• You can analyze your boot process with systemd-analyze and try to find potential points for tweaking:

  $ systemd-analyze
  

4. Useful commands

• Start unit/service manually:

  systemctl start UNITNAME
  

• Restart a unit/service:

  systemctl restart UNITNAME
  

• Reload a units/services configuration:

  systemctl reaload UNITNAME
  

• Stop unit/service manually:

  systemctl stop UNITNAME
  

• See a units/services state:

  systemctl status UNITNAME
  

• Disable a unit/service:

  systemctl disable UNITNAME
  

• And of course enable a unit/service:

  systemctl enable UNITNAME
  

5. Troubleshooting

• For GNOME3 users: If GNOME3 tells you that something is not all right and that all extensions were deactivated, than you have got a problem with the way the X-Server is started. Quick fix: Use GDM instead of your current LoginManager

• If you have problems during boot, you can remove “quiet” from /etc/default/grub to see whats going on during next boot. It is also always a good idea to take a look at the logs in /var/log/