====== systemd ====== 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 ===== Adoption ===== ClearLinux uses systemd a lot NOT using systemd: * gentoo * alpine * slackware ===== Components ===== ^ systemd ^ use ^ what it does ^ alternative or legacy ^ | init | 100 | initialize devices, start services, parallel, fast | SysVInit, initd, upstart, rcopen, runit | | journalctl -xe | 90 | logging | | | logind | 80 | user logins | | | udev | 90 | devices, standardized | fstab | | networkd | 0 | dhcp | network manager | | timesync | 0 | | ? | | timers | 0 | scheduler | cron | | resolved | 0 | DNS resolver | dnsmasq | | boot loader | 0 | uses UEFI | grub | replacements for startup shell scripts: * pm-utils * inetd * acpid * syslog * watchdog * cron * atd ===== Controversy ===== good: standardization, especially of services and devices bad: redundant bloat source: https://www.youtube.com/watch?v=r_haLf5mWhE ===== Units ===== 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 ====== SysV-init vs systemd-init ====== 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. ^ distro ^ init ^ upstart ^ systemd ^ | Debian | | | 8 | | Ubuntu | | 6 (2006) | 15 | | Fedora | | 9 | 15 | | openSUSE | | 11 | 12 | Comparison of init and systemd. ^ ^ init ^ systemd ^ | binary | /etc/init | /lib/systemd/systemd | | states | runlevels 0-6 1 3 5 4 | targets rescue.target multi-user.target graphical.target custom.target | | config | parameters in /etc/inittab file | script files in /etc/init and /etc/init.d | | start daemons | serial | parallel | | | Insert command into /etc/rc.local | | systemd init Units ===== Systemctl ===== * $ 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 ===== Journalctl ===== Location of unit files, in priority order. * /lib/systemd/system # system default * /run/systemd/system # override * /etc/systemd/system # override ====== Start a program at boot ====== 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 ====== systemd ====== 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 ===== Controversy over systemd ===== 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 ===== systemd service ===== $ sudo service gdm stop # gdm = Gnome Desktop Manager $ sudo service gdm start ===== Components ===== 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