mirror of
https://git.yoctoproject.org/poky
synced 2026-03-06 23:39:40 +01:00
ea2feb23bc
The INIT_MANAGER variable was added in 3.0 but it seems we didn't get around to documenting it yet. I have added a variable glossary entry and made the basic adjustment of the "Using systemd Exclusively" section in the dev manual, however I think the latter section still needs work. (From yocto-docs rev: 602c0e8f770516256dab04edfd887377303c06bb) Signed-off-by: Paul Eggleton <bluelightning@bluelightning.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
78 lines
3.1 KiB
ReStructuredText
78 lines
3.1 KiB
ReStructuredText
.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
|
|
|
|
Selecting an Initialization Manager
|
|
***********************************
|
|
|
|
By default, the Yocto Project uses SysVinit as the initialization
|
|
manager. However, there is also support for systemd, which is a full
|
|
replacement for init with parallel starting of services, reduced shell
|
|
overhead and other features that are used by many distributions.
|
|
|
|
Within the system, SysVinit treats system components as services. These
|
|
services are maintained as shell scripts stored in the ``/etc/init.d/``
|
|
directory. Services organize into different run levels. This
|
|
organization is maintained by putting links to the services in the
|
|
``/etc/rcN.d/`` directories, where `N/` is one of the following options:
|
|
"S", "0", "1", "2", "3", "4", "5", or "6".
|
|
|
|
.. note::
|
|
|
|
Each runlevel has a dependency on the previous runlevel. This
|
|
dependency allows the services to work properly.
|
|
|
|
In comparison, systemd treats components as units. Using units is a
|
|
broader concept as compared to using a service. A unit includes several
|
|
different types of entities. Service is one of the types of entities.
|
|
The runlevel concept in SysVinit corresponds to the concept of a target
|
|
in systemd, where target is also a type of supported unit.
|
|
|
|
In a SysVinit-based system, services load sequentially (i.e. one by one)
|
|
during init and parallelization is not supported. With systemd, services
|
|
start in parallel. Needless to say, the method can have an impact on
|
|
system startup performance.
|
|
|
|
If you want to use SysVinit, you do not have to do anything. But, if you
|
|
want to use systemd, you must take some steps as described in the
|
|
following sections.
|
|
|
|
Using systemd Exclusively
|
|
=========================
|
|
|
|
Set the :term:`INIT_MANAGER` variable in your distribution configuration
|
|
file as follows::
|
|
|
|
INIT_MANAGER = "systemd"
|
|
|
|
This will enable systemd and remove sysvinit components from the image.
|
|
See ``meta/conf/distro/include/init-manager-systemd.inc`` for exact
|
|
details on what this does.
|
|
|
|
Using systemd for the Main Image and Using SysVinit for the Rescue Image
|
|
========================================================================
|
|
|
|
Set these variables in your distribution configuration file as follows::
|
|
|
|
DISTRO_FEATURES:append = " systemd"
|
|
VIRTUAL-RUNTIME_init_manager = "systemd"
|
|
|
|
Doing so causes your main image to use the
|
|
``packagegroup-core-boot.bb`` recipe and systemd. The rescue/minimal
|
|
image cannot use this package group. However, it can install SysVinit
|
|
and the appropriate packages will have support for both systemd and
|
|
SysVinit.
|
|
|
|
Using systemd-journald without a traditional syslog daemon
|
|
==========================================================
|
|
|
|
Counter-intuitively, ``systemd-journald`` is not a syslog runtime or provider,
|
|
and the proper way to use systemd-journald as your sole logging mechanism is to
|
|
effectively disable syslog entirely by setting these variables in your distribution
|
|
configuration file::
|
|
|
|
VIRTUAL-RUNTIME_syslog = ""
|
|
VIRTUAL-RUNTIME_base-utils-syslog = ""
|
|
|
|
Doing so will prevent ``rsyslog`` / ``busybox-syslog`` from being pulled in by
|
|
default, leaving only ``journald``.
|
|
|