Use Cases

From https://wiki.debian.org/Debate/initsystem/systemd

Squishy stuff

• initial advertisement
  • clean and efficient design
  • new functionality that makes the life of users, administrators and packagers easier
  • reliable and easy service management
  • cleaner dependencies
  • service monitoring
  • security features
  • global system integration
  • session management
  • multi-seat
  • unified system interfaces
  • integration with udev, D-Bus and other system services
  • speed improvements
  • shell-less design (?!)
  • ability to remove optional components
  • lower memory footprint
• architecture
  • handle the entire boot process from head to toe, without needing to use any of the existing shell scripts.
    • what is "the entire boot proces"? What do alternatives not handle that systemd does and why should systemd be in charge of them?
    • why is not using legacy scripts a goal?
  • CLI is argued by proponents to be the best available.
  • "unit" file format is asserted to be a selling point.
  • Quick boot times.
    • Systemd advocates claim 1 second boot times, presumably timed from start of process 1 to computer being usable.
    • I can attest that this is not always the case, such as when the network is misbehaving. Alternatives may not be better, but we have to be realistic.
  • Advocates assert the transition plan was easy. This applies to us in our goal of making ours a drop-in replacement.
• functionality
  • Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly
  • Systemd extends the logging features of the system in many ways with journald, and can remain integrated with the existing rsyslog daemon. Logs are in a structured f
  • Systemd's virtual TTY management allows real multi-seat support, and revoking access to input devices on session switch
  • Systemd can trivially add security settings to a service without any need to patch it: user/group change, chroot, private network, private /tmp, read-only access to parts of the tree, tcp wrappers, filtering system calls, ?NoNewPrivileges (kernel feature to avoid privilege changes), limiting effective capabilities, limiting whatever the kernel provides in an integrated manner (device bandwidth, CPU usage, memory usage, OOM settings, nice levels, timer slack, ulimits…)

Less squishy

• Systemd provides a D-Bus API to control service management and access system settings, as well as bindings to do that from Python, node.js, php, lua, Qt… GNOME is relying on these services.
  • NOTABLY, anything with a sane CLI or RESTful API is automatically readily accessible from these platforms. This is not an impressive capability.
• Systemd can run without any configuration change in a virtual machine or a container. It will automatically skip unwanted services
  • whoopty dooo
• Systemd provides full watchdog support. If configured to do so, PID 1 will enable the watchdog and will perform the watchdog notifications itself. Suitably configured services use systemd as the watchdog, and notify it regularly to be considered alive. In this way, the whole system is supervised, with the hardware supervising systemd, and systemd supervising the rest.
• Systemd can be used used inside the initramfs (see dracut on Fedora), which means the same code serves an additional purpose, and there's less stuff to maintain. It can also hand control back to the initramfs at shutdown, making it possible to cleanly unmount the root filesystem even in very complicated, stacked setups.
  • I'm pretty sure this is true of existing alternatives as well?
• Systemd is introspectable and easy to debug: in addition to the ability to provide debugging output and a debugging shell much earlier in the boot process than other boot systems can, systemd features command-line and GUI tools to debug the state of individual services and understand precisely why they fail to work correctly.
  • I (rdeforest) need to look into this since it would help in the situation I mentioned before with wonky net slowing down boot
  • On the other hand, Debian already had this in the form of the initramfs having busybox and being easy to extend
• Systemd is moving strongly in the direction of configuration-less system (i.e. “empty /etc/”). So /etc/fstab might be empty on a system with a GPT partition table, with partitions mounted in appropriate places based on their type id. This means that the configuration of the common one-machine-one-disk setup becomes even simpler.
  • I'm not sure if this is good or not. /etc has been a public interface for a long time, so this is likely breaking compatibility with legacy software.
  • This "feature" may not be a goal of the NiceSystem

Observed

Here we note aspects of systemd in the wild. What does /sbin/init do? That kind of thing.

PID 1 on a running desktop

rdeforest@bunowen:~
$ ls -l /sbin/init
lrwxrwxrwx 1 root root 20 Aug 17 22:03 /sbin/init -> /lib/systemd/systemd

rdeforest@bunowen:~
$ ls -l /lib/systemd/systemd
-rwxr-xr-x 1 root root 1034816 Aug 17 22:03 /lib/systemd/systemd

rdeforest@bunowen:~
$ ps --pid 1 u
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0 202700  7104 ?        Ss   Aug03   0:11 /lib/systemd/systemd --system --deserialize 19

rdeforest@bunowen:~
$ ldd /lib/systemd/systemd
	linux-vdso.so.1 (0x00007ffdf1ba0000)
	libsystemd-shared-231.so => /lib/systemd/libsystemd-shared-231.so (0x00007fc62d1b2000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fc62cf67000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fc62cd5e000)
	libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 (0x00007fc62cb19000)
	libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007fc62c90a000)
	libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007fc62c6e1000)
	libkmod.so.2 => /lib/x86_64-linux-gnu/libkmod.so.2 (0x00007fc62c4ca000)
	libapparmor.so.1 => /lib/x86_64-linux-gnu/libapparmor.so.1 (0x00007fc62c2b9000)
	libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fc62c06e000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc62be51000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc62bab0000)
	libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007fc62b8a9000)
	liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007fc62b686000)
	libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007fc62b377000)
	libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007fc62b16d000)
	libidn.so.11 => /lib/x86_64-linux-gnu/libidn.so.11 (0x00007fc62af39000)
	/lib64/ld-linux-x86-64.so.2 (0x000055f12c889000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fc62acc6000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc62aac1000)
	libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007fc62a8bb000)
	libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fc62a677000)
	libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007fc62a463000)
	libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007fc62a25d000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fc62a058000)

rdeforest@bunowen:~
$ uptime
 16:45:45 up 29 days, 21:27,  2 users,  load average: 0.03, 0.11, 0.12

rdeforest@bunowen:~
$ 

Explorability: How do I change when/how a process runs?

Going to see how hard it is to figure out how to modify the boot and process management config.