System V (Sys V), systemd, Upstart, runit

• 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

• Contra systemd, upstart

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/

• Systemd Container

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