summaryrefslogtreecommitdiffstats
path: root/documentation/dev-manual/init-manager.rst
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/dev-manual/init-manager.rst')
-rw-r--r--documentation/dev-manual/init-manager.rst162
1 files changed, 162 insertions, 0 deletions
diff --git a/documentation/dev-manual/init-manager.rst b/documentation/dev-manual/init-manager.rst
new file mode 100644
index 0000000000..ddce82b81f
--- /dev/null
+++ b/documentation/dev-manual/init-manager.rst
@@ -0,0 +1,162 @@
1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3.. _init-manager:
4
5Selecting an Initialization Manager
6***********************************
7
8By default, the Yocto Project uses :wikipedia:`SysVinit <Init#SysV-style>` as
9the initialization manager. There is also support for BusyBox init, a simpler
10implementation, as well as support for :wikipedia:`systemd <Systemd>`, which
11is a full replacement for init with parallel starting of services, reduced
12shell overhead, increased security and resource limits for services, and other
13features that are used by many distributions.
14
15Within the system, SysVinit and BusyBox init treat system components as
16services. These services are maintained as shell scripts stored in the
17``/etc/init.d/`` directory.
18
19SysVinit is more elaborate than BusyBox init and organizes services in
20different run levels. This organization is maintained by putting links
21to the services in the ``/etc/rcN.d/`` directories, where `N/` is one
22of the following options: "S", "0", "1", "2", "3", "4", "5", or "6".
23
24.. note::
25
26 Each runlevel has a dependency on the previous runlevel. This
27 dependency allows the services to work properly.
28
29Both SysVinit and BusyBox init are configured through the ``/etc/inittab``
30file, with a very similar syntax, though of course BusyBox init features
31are more limited.
32
33In comparison, systemd treats components as units. Using units is a
34broader concept as compared to using a service. A unit includes several
35different types of entities. ``Service`` is one of the types of entities.
36The runlevel concept in SysVinit corresponds to the concept of a target
37in systemd, where target is also a type of supported unit.
38
39In systems with SysVinit or BusyBox init, services load sequentially (i.e. one
40by one) during init and parallelization is not supported. With systemd, services
41start in parallel. This method can have an impact on the startup performance
42of a given service, though systemd will also provide more services by default,
43therefore increasing the total system boot time. systemd also substantially
44increases system size because of its multiple components and the extra
45dependencies it pulls.
46
47On the contrary, BusyBox init is the simplest and the lightest solution and
48also comes with BusyBox mdev as device manager, a lighter replacement to
49:wikipedia:`udev <Udev>`, which SysVinit and systemd both use.
50
51The ":ref:`device-manager`" chapter has more details about device managers.
52
53Using SysVinit with udev
54=========================
55
56SysVinit with the udev device manager corresponds to the
57default setting in Poky. This corresponds to setting::
58
59 INIT_MANAGER = "sysvinit"
60
61Using BusyBox init with BusyBox mdev
62====================================
63
64BusyBox init with BusyBox mdev is the simplest and lightest solution
65for small root filesystems. All you need is BusyBox, which most systems
66have anyway::
67
68 INIT_MANAGER = "mdev-busybox"
69
70Using systemd
71=============
72
73The last option is to use systemd together with the udev device
74manager. This is the most powerful and versatile solution, especially
75for more complex systems::
76
77 INIT_MANAGER = "systemd"
78
79This will enable systemd and remove sysvinit components from the image.
80See :yocto_git:`meta/conf/distro/include/init-manager-systemd.inc
81</poky/tree/meta/conf/distro/include/init-manager-systemd.inc>` for exact
82details on what this does.
83
84Controling systemd from the target command line
85-----------------------------------------------
86
87Here is a quick reference for controling systemd from the command line on the
88target. Instead of opening and sometimes modifying files, most interaction
89happens through the ``systemctl`` and ``journalctl`` commands:
90
91- ``systemctl status``: show the status of all services
92- ``systemctl status <service>``: show the status of one service
93- ``systemctl [start|stop] <service>``: start or stop a service
94- ``systemctl [enable|disable] <service>``: enable or disable a service at boot time
95- ``systemctl list-units``: list all available units
96- ``journalctl -a``: show all logs for all services
97- ``journalctl -f``: show only the last log entries, and keep printing updates as they arrive
98- ``journalctl -u``: show only logs from a particular service
99
100Using systemd-journald without a traditional syslog daemon
101----------------------------------------------------------
102
103Counter-intuitively, ``systemd-journald`` is not a syslog runtime or provider,
104and the proper way to use ``systemd-journald`` as your sole logging mechanism is to
105effectively disable syslog entirely by setting these variables in your distribution
106configuration file::
107
108 VIRTUAL-RUNTIME_syslog = ""
109 VIRTUAL-RUNTIME_base-utils-syslog = ""
110
111Doing so will prevent ``rsyslog`` / ``busybox-syslog`` from being pulled in by
112default, leaving only ``systemd-journald``.
113
114Summary
115-------
116
117The Yocto Project supports three different initialization managers, offering
118increasing levels of complexity and functionality:
119
120.. list-table::
121 :widths: 40 20 20 20
122 :header-rows: 1
123
124 * -
125 - BusyBox init
126 - SysVinit
127 - systemd
128 * - Size
129 - Small
130 - Small
131 - Big [#footnote-systemd-size]_
132 * - Complexity
133 - Small
134 - Medium
135 - High
136 * - Support for boot profiles
137 - No
138 - Yes ("runlevels")
139 - Yes ("targets")
140 * - Services defined as
141 - Shell scripts
142 - Shell scripts
143 - Description files
144 * - Starting services in parallel
145 - No
146 - No
147 - Yes
148 * - Setting service resource limits
149 - No
150 - No
151 - Yes
152 * - Support service isolation
153 - No
154 - No
155 - Yes
156 * - Integrated logging
157 - No
158 - No
159 - Yes
160
161.. [#footnote-systemd-size] Using systemd increases the ``core-image-minimal``
162 image size by 160\% for ``qemux86-64`` on Mickledore (4.2), compared to SysVinit.