doc/linux/DINIT-AS-INIT.md

   1 ## Dinit as init: using Dinit as your Linux system's init
   2
   3 Modern linux is a relatively complex system, these days. You can use Dinit,
   4 in conjunction with other software, to boot your system and replace your current
   5 init system (which on most main distributions is now Systemd, Sys V init, or
   6 OpenRC).
   7
   8 Be warned that it is not a trivial task to take a system based on a typical
   9 Linux distribution and make it instead boot with Dinit. You need to set up
  10 suitable service description files for your system; at present there are no
  11 automated conversion tools for converting service descriptions or startup
  12 scripts from other systems.
  13
  14 The additional software required can be broken into _essential_ and
  15 _optional_ packages, which are detailed in following sections. For example service
  16 files, please check the "services" subdirectory.
  17
  18
  19 # General notes
  20
  21 It is common to use "devtmpfs" on /dev, and the kernel can actually mount it
  22 there before it even starts the init process, which can be quite handy; for
  23 one thing it means that a range of device nodes will be available by default
  24 (including /dev/console, which dinit may need to display any output, as well
  25 as the block device used for the root mount, which must be available in
  26 order to perform the initial fsck). You must configure your kernel
  27 appropriately for this to happen.
  28
  29 (actually, it seems that dinit manages output without /dev/console; probably
  30 the kernel is giving it appropriate stdin/out/err file descriptors. I'm not
  31 sure if this was the case for older kernels).
  32
  33 The /dev filesystem on linux after boot is usually managed by a "device node
  34 manager", such as Udev (which is now distributed only with Systemd) or
  35 Eudev. Even this is technically optional - you can still populate your root
  36 filesystem with device nodes directly - but I highly recommend using an
  37 automated system.
  38
  39 Various other virtual filesystems are mounted as standard on Linux these
  40 days. They include:
  41
  42 - /sys - sysfs - representation of devices, buses, drivers etc; used by udev etc.
  43 - /sys/fs/cgroup - cgroupfs - control groups
  44 - /proc - procfs - information about running processes, and various kernel
  45   interfaces
  46 - /dev/shm - tmpfs - used for shared memory
  47 - /dev/pts - devpts - pseudoterminal devices
  48 - /run - tmpfs - storage for program state (replacement for /var/run); used by
  49   udev and some other programs
  50
  51 These filesystems (particularly /sys, /proc and /run) need to be mounted
  52 quite early as they will be used by early-boot processes.
  53
  54 Many Linux distributions are now built around Systemd. Much of what Systemd
  55 manages was previously managed by other utilities/daemons (syslogd, inetd,
  56 cron, cgmanager, etc) and these can still be used to provide their original
  57 functionality, although at the cost of the losing automated integration.
  58
  59 Some packages may rely on the "logind" functionality of Systemd for
  60 session/seat management. This same functionality is also provided by
  61 ConsoleKit2, though I'm not to what degree nor level of compatibility.
  62
  63 In general I've found it quite possible to run a desktop system with Dinit
  64 in place of SystemD, but my needs are minimal. If you're running a
  65 full-fledged desktop environment like Gnome or KDE you may experience
  66 problems (which, I believe, should not be intractable, but which may require
  67 implementation/shims of Systemd APIs in some cases).
  68
  69 The basic procedure for boot (to be implemented by services) is as follows:
  70
  71 - mount early virtual filesystems
  72 - start device node manager
  73 - trigger device node manager (udevadm trigger --action=add) to add
  74   boot-time device nodes (possibly not necessary if using kernel-mounted
  75   devtmpfs)
  76 - run root filesystem check
  77 - remount root filesystem read-write
  78 - start syslog deamon
  79 - start other daemons as appropriate (dhcpcd, any networking daemons)
  80 - start getty instances virtual terminals
  81
  82 The service description files and scrips in the "services" subdirectory
  83 provide a template for accomplishing the above, but may need some adjustment
  84 for your particular configuration.
  85
  86
  87 # Boot performance compared to Systemd
  88
  89 Boot performance using Dinit suffers slightly compared to Systemd due to
  90 several factors:
  91
  92 - Dinit doesn't handle file system mounts/checks and spawns external
  93   processes and/or scripts to manage these
  94 - In the absence of full udev integration, it is more difficult to start
  95   some services as early as possible. For instance, filesystem mounts need
  96   to wait for the appropriate device to be recognized by the kernel and
  97   exported as a device node; similarly network interfaces need to be
  98   recognized before they are configured. With Dinit, the simplest approach
  99   is to wait until udev "settles" (via "udevadm settle") before attempting
 100   mounts and network configuration etc.
 101 - Dinit doesn't do socket activation (yet). What it can do is pre-open a
 102   socket while it launches a daemon, which probably improves boot times a
 103   little but potentially still results in more daemons getting started than
 104   is strictly necessary.
 105
 106 In the future Dinit might provide functionality to perform basic mounts
 107 without spawning an external process, and will almost certainly support full
 108 socket activation. Some of the more fundamental startup script functionality
 109 might also be offered via some kind of intrinsic service(s). However, where
 110 at all possible, the intention is to keep service functionality separate to
 111 Dinit itself.
 112
 113
 114 # Essential packages for building a Dinit-based system
 115
 116 Other than the obvious system C library and C++ library, you'll need a range
 117 of packages to create a functional Dinit-based system.
 118
 119 First, a device node manager. I recommend "Eudev".
 120
 121 - Eudev - the Gentoo fork of Udev; https://github.com/gentoo/eudev
 122 - Vdev - "a device file manager and filesystem" and a "work in progress";
 123   https://github.com/jcnelson/vdev
 124 - Mdev may also be an option; it is part of the "busybox" utility suite. I
 125   don't personally have any experience with it.
 126
 127 Then, a "getty" and "login" program. Both can be found in the util-linux
 128 package, at: https://www.kernel.org/pub/linux/utils/util-linux
 129
 130 Also provided in the util-linux package are standard utilities such as fsck
 131 and mount. You'll probably want e2fsprogs (or the equivalent for your chosen
 132 filesystem): http://e2fsprogs.sourceforge.net/
 133
 134 The syslog daemon from GNU Inetutils is basic, but functional - which makes
 135 it a good fit for a Dinit-based system. https://www.gnu.org/software/inetutils
 136
 137 You will need a shell script interpreter / command line, for which you have
 138 a range of options. A common choice is GNU Bash, but many distributions are
 139 using Dash as the /bin/sh shell because it is significantly faster (affecting
 140 boot time).
 141
 142 - Bash: https://www.gnu.org/software/bash
 143 = Dash: http://gondor.apana.org.au/~herbert/dash
 144
 145
 146 # Optional packages for building a Dinit-based system
 147
 148 ConsoleKit2, to act as seat/sesion manager (functionality otherwise
 149 provided by Systemd):
 150 https://github.com/ConsoleKit2/ConsoleKit2
 151
 152 cgmanager, the control group manager; you probably want this if you use
 153 ConsoleKit2, and maybe if you want to use containers:
 154 https://github.com/lxc/cgmanager
 155
 156 (However, I believe that cgmanage works with the old v1 cgroups interface.
 157 I expect that v2 cgroups together with cgroup namespaces as found in newer
 158 kernels will render it obselete).
 159
 160 Both ConsoleKit2 and cgmanager use Dbus:
 161 https://dbus.freedesktop.org/