- Red Hat is the inventor and primary booster of systemd, so the best distros for playing with it are Red Hat Enterprise Linux, RHEL clones like CentOS and Scientific Linux
Experienced RH users can still use service and
chkconfig in RH 7, but it's long
past time to dump them in favor of native
systemd utilities.
systemd has outpaced them, and service and
chkconfig do not support native
systemd services.
Our beloved /etc/
inittab is no more.
Instead, we have a /etc/
systemd/system/ directory chock-full of
symlinks to files in /
usr/lib/
systemd/system/.
/
usr/lib/
systemd/system/ contains init scripts; to start a service at boot
it must be linked to /etc/
systemd/system/.
The
systemctl command does this for you when you enable a new service
#
systemctl enable clamd@scan.service
ClamAV offers both
systemd and
SysVInit init scripts
$
yum search
clamav
clamav-server-
sysvinit.noarch
clamav-server-
systemd.noarch
https://lcom.static.linuxfound.org/images/stories/41373/Systemd-components.png
A brief overview and history of
systemd — the Linux process manager
Understanding and Using
Systemd
Full system roll-back and systemd in SUSE Linux Enterprise 12
RHEL 7 Boot Process
- There are three possible states for a service: enabled or disabled, and static
Enabled means it has a
symlink in a
.wants directory
Disabled means it does not.
Static means the service is missing the [Install] section in its init script, so you cannot enable or disable it.
Static services are usually dependencies of other
services, and
are controlled automatically.
for anyone who
does care about boot times you can run a command to see how long every program and service takes to start up
$ systemd-analyze blame
https://www.
linux.com/learn/understanding-and-using-systemd
- manage many aspects of your server, from services to mounted devices and system state
In
systemd, a unit refers to any resource that the system knows how to operate on and manage.
These resources are defined using configuration files called unit files.
When a unit with this directive
is enabled,
a directory will be created within /etc/
systemd/system named after the specified unit with
.wants appended to the end.
For instance, if the current unit has
WantedBy=multi-user
.target, a directory called multi-user
.target
.wants will be created within /etc/
systemd/system
https://www.digitalocean.com/community/tutorials/understanding-systemd-units-and-unit-files
- Init process in Linux is the first process to start on boot, and it tracks all the system services and Daemons.
Various Linux Distros have created different implementations of the standard init systems.
Currently, the most popular init system adopted by various Linux distros is
systemd.
If your target system is not using the
systemd init system, then you can use the Ansible service module
http://www.mydailytutorials.com/linux-services-using-ansible-systemd-and-service-modules/
- SysVinit Vs Systemd Cheatsheet
systemd is a new init system
systemd is compatible with
SysV and LSB init scripts.
systemd is the first process get started by
kernel and holding PID 1.
systemctl is
command line utility and primary tool to manage the
systemd daemons/services such as (start, restart, stop, enable, disable, reload & status).
systemd uses
.service files Instead of bash scripts (
SysVinit uses).
systemd sorts all daemons into their own Linux
cgroups and you can see the system hierarchy by exploring /
cgroup/
systemd file.
three init systems
are widely used in Linux.
System V (Sys V): System V (Sys V) is one of the first and traditional init system for Unix
like operating system.
Upstart: Upstart is an event-based replacement for the /
sbin/init daemon.
systemd:
Systemd is a new init system and system manager
which was implemented/adapted into all the major Linux distributions over the traditional
SysV init systems.
https://www.2daygeek.com/sysvinit-vs-systemd-cheatsheet-systemctl-command-usage/
- Systemd (stylized as systemd) is a suite of software that provides fundamental building blocks for a Linux operating system.Among other features, it includes the systemd "System and Service Manager,"[5] an init system used to bootstrap the user space and to manage system processes after booting. It is a replacement for the UNIX System V and Berkeley Software Distribution (BSD) init systems and, as of 2015, the majority of Linux distributions have adopted systemd as their default init system
One of the main goals of the
systemd project is unification of basic Linux configurations and service behaviors across all Linux distributions.
The name
systemd adheres to the Unix convention of naming daemons by appending the letter d.
https://en.wikipedia.org/wiki/Systemd
- In general, bootstrapping usually refers to a self-starting process that is supposed to proceed without external input. In computer technology the term (usually shortened to booting) usually refers to the process of loading the basic software into the memory of a computer after power-on or general reset, especially the operating system which will then take care of loading other software as needed.
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.
systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and
automount points, and implements an elaborate transactional dependency-based service control logic.
systemd supports
SysV and LSB init scripts and works as a replacement for
sysvinit. Other parts include a logging daemon, utilities to control basic system configuration like the hostname, date, locale, maintain a list of logged-in users and running containers and virtual machines, system accounts, runtime directories and settings, and daemons to manage
simple network configuration, network time synchronization, log forwarding, and name resolution.
https://www.freedesktop.org/wiki/Software/systemd/
- On systems based on SysVinit, init is the first process that is executed once the Linux kernel loads.
inittab is the startup configuration file for init
located in /etc. It contains directions for init on what programs and scripts to run when entering a specific
runlevel.
https://wiki.archlinux.org/index.php/SysVinit
They depend on
DBus,
which means that if
DBus is not
working system initialization cannot begin.
If makers of
systemd and upstart
really wanted to contribute to F/OSS community, they could just improve
sysvinit, init scripts and add additional software that can
be used from shell scripts to achieve the same features they provide. Which is basically what
openrc did.
Contra
systemd
Not portable, by design; uses Linux-specific functionality not available on other platforms.
Violates traditional UNIX principles of simplicity and the separation of kernel/
initsystem/
userland duties such that components are interchangeable.
"
Systemd ships a growing number of useful, unified command-line interfaces for system settings and control (
timedatectl,
bootctl,
hostnamectl,
loginctl,
machinectl, kernel-install,
localectl)."
"unified" is a bad replacement for complying to standards (such as POSIX) and conventions and power must go along with responsibility
Contra upstart
Can't set proper dependencies until everything has converted from
SysV init files to Upstart jobs.
Contra
OpenRC
This
initsystem is the least familiar to most of us yet (only recently packaged, and still in
Debian's NEW queue).
Contra
sysvinit
init scripts are not really user edit-able configuration.
No real process supervision, e.g. daemons
are not automatically restarted when they crash.
No integration with
udev, services cannot be started when specific hardware
is discovered.
https://wiki.debian.org/Debate/initsystem/sysvinit
- Runit is a daemontools-inspired process supervision suite that also provides a program suitable for running as process 1. It can be used as alternative to sysvinit or systemd, either by itself or in conjunction with OpenRC. It can also be used as a helper for supervising OpenRC services.
https://wiki.gentoo.org/wiki/Runit
- runit is a cross-platform Unix init scheme with service supervision, a replacement for sysvinit, and other init schemes. It runs on GNU/Linux, *BSD, MacOSX, Solaris, and can easily be adapted to other Unix operating systems.
http://smarden.org/runit/
- Comparison of init systems
https://wiki.gentoo.org/wiki/Comparison_of_init_systems
- systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, maintains mount and automount points, and implements an elaborate transactional dependency-based service control logic
https://www.freedesktop.org/wiki/Software/systemd/
The docker daemon was designed to provide a simple means of starting, stopping and managing containers. It
was not originally designed to bring up an entire Linux system or manage services for such things as start-up order, dependency checking, and failed service recovery
https://molecule.readthedocs.io/en/latest/examples.html#id4
- CHAPTER 3. USING SYSTEMD WITH CONTAINERS
This chapter describes how you can use the
systemd initialization service to work with containers in two different ways:
Starting Containers with
systemd: By setting up a
systemd unit file on your host computer, you can have the host automatically start, stop, check the status, and otherwise manage a container as a
systemd service.
Starting services within a container using
systemd: Many Linux services (Web servers, file servers, database servers, and so on)
are already packaged for Red Hat Enterprise Linux to run as
systemd services. If you are using the latest RHEL container image, you can set the RHEL container image to start the
systemd service, then automatically start selected services within the container when the container starts up.
3.2. Starting services within a container using
systemd
Start the /
sbin/init process (the
systemd service) to run as PID 1 within the container.
Start all
systemd services that
are installed and enabled within the container, in order of dependencies.
Allow
systemd to restart services or kill zombie processes for services started within the container.
The general steps for building a container
that is ready to
be used as a
systemd services is:
Install the package containing the
systemd-enabled service inside the container. This can include dozens of services that come with RHEL, such as Apache Web Server (
httpd), FTP server (
vsftpd), Proxy server (squid), and many others. For this example, we
simply install an Apache (
httpd) Web server.
Use the
systemctl command to enable the service inside the container.
Add data for the service to use in the container (in this example, we add a Web server test page). For a real deployment, you would probably connect to outside storage.
Expose any ports needed to access the service.
Set /
sbin/init as the default process to start when the container runs
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_atomic_host/7/html/managing_containers/using_systemd_with_containers
