org

• controversy
• sysv vs systemd
• init vs all other components
• how to start a program at boot

A software suite that provides an array of system components.

Entomology. The name systemd:

• observes the linux convention of naming daemons with a trailing d
• playing on the concept, System D, an idea popularized by Anthony Bourdain, referring to the ability to adapt, to make do, to be resourceful.

Project name, github source, Lennart Poettering, Berlin.

Makes use of

• cgroups
• dbus

ClearLinux uses systemd a lot

NOT using systemd: * gentoo * alpine * slackware

replacements for startup shell scripts:

• pm-utils
• inetd
• acpid
• syslog
• watchdog
• cron
• atd

good: standardization, especially of services and devices

bad: redundant bloat

source: https://www.youtube.com/watch?v=r_haLf5mWhE

unit = a thing that is managed by systemd. Does not have to be a service. Does not have to be started at boot.

Uses the words service and unit. A service is a type of unit.

service vs unit

unit file paths

• /lib/systemd/system - for package-installed units, get replaced on package update
• /etc/systemd/system - for administrator-configured units
• /run/systemd/system - for non-persistent runtime modifications

unit file name convention: name.type examples:

• consul.service
• ssh.socket

Service Unit Types

• simple - for executables which run without daemonising
• forking - for executables which daemonise themselves
• oneshot - usually short-lived programs which run to completion and terminate
• notify - for executables which will notify systemd when they are started and available for work

Unit Commands

$ systemctl enable consul.service # makes it start at boot
$ systemctl start consul.service
$ systemctl stop consul.service
$ systemctl restart consul.service
$ systemctl status consul.service

Unit File Format [Unit] key=value [Service] [Install]

When a service starts multiple processes, they are contained within a CGroup. This allows a service to be started, stopped and restarted, because all of the processes can be started as a group.

Common BootStrapping Pattern

$ apt install consul # the general purpose options are set in /lib/systemd/system/consul
$ apt install consul-bootstrap-aws # platform specifics are set in /etc/systemd/system/consul
$ apt install consul-bootstrap-azure

Target Units

• replacements for runlevels
• can create our own targets (runlevels)
• a target is reached when all dependent services are started

Socket Units

python program

• import github.com/coreos/go-systemd/activation

Timer Units

• replaces cron

resource accounting

Unit file types: .service .socket .device .mount .automount .swap .target .path .timer (which can be used as a cron-like job scheduler[54]) .snapshot .slice (used to group and manage processes and resources[55]) .scope

init

• systemctl
• each component has a *ctl file and also daemons and configuration files

history

• improvements encompassed by systemd
• not everything has to be started at boot
• those things that are started can be started in parallel.
• no need to specify the order in which things install.
• no need to wait for one thing to start before the other things are started
• a service with multiple processes, all processes are contained in a CGroup and can be started, stopped and restarted together.
• can specify a service should be restarted after a crash

journal

• how do you use this?

terms:

• process
• thread
• task
• job
• cgroup

process running possibilities

• foreground
• background
• terminal-associated

client-server

• client
• server
• service

list all current running services

$ service --status-all

list all current systemd processes

$ ps -e|grep systemd
    1 ?        00:02:35 systemd
  309 ?        00:00:01 systemd-journal
  342 ?        00:00:02 systemd-udevd
  725 ?        00:00:02 systemd-resolve
  727 ?        00:00:00 systemd-timesyn
  809 ?        00:00:10 systemd-logind
 1448 ?        00:00:01 systemd

Kernel interface libudev

NetworkManager A software utility that provides a high-level interface for the configuration of the network interfaces.

NetworkManager sits on top of libudev and other kernel interfaces and other daemons.

Components

nm-applet - graphical user interface implemented as GNOME applet

nmcli - command-line interface

nmtui - text-based user interface

===== Boot Targets

$ systemctl get-default   # show boot target
graphical.target

$ systemctl isolate graphical.target   # start a different target right now
$ systemctl set-default graphical.target  # change the boot target

Run Levels

• 0 system shutdown
• 1 single user mode, no network, essential services only (maintenance mode)
• 2 not used
• 3 multi-user mode
• 4 not used
• 5 multi-user mode plus graphical mode login
• 6 system restart

Run levels are managed by /sbin/init

Run level is defined by a kernel parameter or in the /etc/inittab file.

There are 3 paradigms to manage services in Ubuntu.

• `System V init`,
• `upstart` and
• `systemd`.

As of Ubuntu 18.04, it is `systemd`. [smwikipedia](https://unix.stackexchange.com/users/4061/smwikipedia) [Aug 21 '18 at 6:14](https://unix.stackexchange.com/questions/34405/file-in-ubuntu-equivalent-to-etc-inittab-file-in-redhat#comment844173_34406)

Ubuntu does not use runlevels, nor etc/inittab

SysV init used etc/inittab

In Ubuntu 18, the init binary is soft linked to systemd.

$ ls -al /sbin/init
/sbin/init -> /lib/systemd/systemd

init, aka sysvinit, as in System 5 init

Upstart, first introduced in Ubuntu 6 in 2006

systemd, adopted in Ubuntu 15

From init, through upstart, to systemd.

For booting, many linux distributions originally used init, aka sysvinit, taken from System V Unix. Later, many distributions replaced init with upstart, and later still with systemd.

Boot system adoption by distribution release number.

Comparison of init and systemd.

systemd init

Units

• $ sudo systemctl poweroff
• $ sudo systemctl reboot
• $ sudo systemctl rescue
• $ systemctl list-unit-files –type=target # list all targets
• $ systemctl get-default # show current boot target
• $ systemctl list-dependencies multi-user.target # list unit files tied to a target
• $ sudo systemctl set-default multi-user.target # set target for boot
• $ sudo systemctl isolate multi-user.target # activate target right now

Location of unit files, in priority order.

• /lib/systemd/system # system default
• /run/systemd/system # override
• /etc/systemd/system # override

Add a command into /etc/rc.local. That probably still works, but a newer more complicated method is to create a unit file that defines a systemd service.

1. Create a script or executable.

$ vi myservice.sh

2. Copy the script to /usr/bin/ and make it executable. (Notice that /bin is soft linked to /usr/bin, which means I will be putting my own service in with the system services.)

$ sudo cp myservice.sh /usr/bin/myservice.sh
$ sudo chmod +x /usr/bin/myservice.sh

3. Create a unit file to define a systemd service that will manage your script.

[Unit]
Description=Skateboard monitor webservice.

[Service]
Type=simple
ExecStart=/bin/bash /usr/bin/webservice.sh

[Install]
WantedBy=multi-user.target

4. Copy the unit file to /etc/systemd/system and give it permissions.

$ sudo cp myservice.service /etc/systemd/system/myservice.service
$ sudo chmod 644 /etc/systemd/system/myservice.service

5. Test the service.

$ sudo systemctl start myservice
$ sudo systemctl status myservice
$ sudo systemctl stop myservice

6. Enable the service. (Put it in the boot sequence.)

$ sudo systemctl enable myservice  # put service into boot sequence  

launchd, introduced in macOS replaced initd, crond, and many others. Services are started when needed and not all at boot. Makes boot faster.

systemd is a rip-off of launchd, author Lennart Poettering

Startup mechanism

From bootstrap to service handling

From service manager to system manager

systemd started as init system and spiraled out

Daemons are userspace

System level, between kernel and userspace

Despite the controversy, systemd was adopted widely between 2011 and 2015

Source: [https://www.youtube.com/watch?v=o_AIw9bGogo](https://www.youtube.com/watch?v=o_AIw9bGogo)

Complaints

* Violates unix philosophy. What should be separate modules are all folded into one project, making it bloated and monolithic.

• Response: It is still made up of separate binaries.

* Lennart Poettering manages the systemd project and he is a jerk

Pros

* journald * cgroups, compared as superior to FreeBSD Jails * user-level units, running a daemon as a user instead of root, drop it into a folder and it starts * Message Transport, heavy use of dbus * RPC Framework, remote procedure call * Service Lifecycle * Automation via API * Containers, made possible by cgroups * The system layer, between kernel and user * Consistent device naming * Better log/event/audit handling, binary is ok * A new model of an application, multiple executables in a container

Notes:

* Examples of New ways of thinking: (not systemd specific)

• web api’s
• containers

* Debian can run on FreeBSD kernel * Debian was reluctant to adopt systemd

$ sudo service gdm stop  # gdm = Gnome Desktop Manager
$ sudo service gdm start

init

logind

journald - writes to binary files (controversial)

udev - managing virtual device files

task scheduler - ala cron

networkd -

systemctl

hostnamectl

timedatectl

$ ps -e | grep systemd
    1 ?        00:01:18 systemd
  309 ?        00:00:00 systemd-journal
  342 ?        00:00:01 systemd-udevd
  725 ?        00:00:01 systemd-resolve
  727 ?        00:00:00 systemd-timesyn
  809 ?        00:00:06 systemd-logind
 1448 ?        00:00:00 systemd