| 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889 |
- .. 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 these variables in your distribution configuration file as follows::
- DISTRO_FEATURES:append = " systemd"
- VIRTUAL-RUNTIME_init_manager = "systemd"
- You can also prevent the SysVinit distribution feature from
- being automatically enabled as follows::
- DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
- Doing so removes any
- redundant SysVinit scripts.
- To remove initscripts from your image altogether, set this variable
- also::
- VIRTUAL-RUNTIME_initscripts = ""
- For information on the backfill variable, see
- :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`.
- 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``.
|
