This article is my own and based on various other sources from the internet. If you have something to say please provide your feedback in the comment section below.
what is systemd:
systemd is a service manager/init process used to bootstrap the userspace and manage all process.
Already systemd is the default init system for many operating systems including redhat, ubuntu, fedora and many others. Systemd is useful for a system administrator, as it provides many features to manage the OS efficiently.
Here are the few reasons why systemd is needed.
Note: Some of the reasons below are disagreed by the developers and traditional SysV users
Speedup the boot by increasing the concurrency of process startup
Better process management – by babysitting process
Better dependencies management of process during startup
Reduce computational overhead of shell script used during boot
How systemd increases concurrency of process start
In Linux, services can be provided by INET socket or D-bus.
For INET socket:
Each process has dependencies. Example NFS mounts daemon waits for RPC bind.sock and portmapper IP port.
Similarly, each daemon has its own dependencies and it may have to wait for the socket opening. Further, each daemon may have other daemon dependencies, this will further increase the wait time.
So the idea of the systemd is to start the sockets before the daemon start. Although socket has no much dependencies, we can create all the sockets for all daemon at one step. If all sockets are created then we can start all the daemons at the same time currently.
There may be wait time if a daemon needs another daemon dependency the daemon is not started, But that’s ok according to systemd.
We still reduce the wait time of socket creation. By doing this we achieve following things
Boot time reduced
Dependencies between service no longer exist
Startup is parallelized
For D bus
D-bus can also be activated using the same logic of traditional INET socket.
Instead of starting the service at startup, we can start the first time it is accessed using bus activation.
It also provides options for starting up provider and consumer at the same time.
During system boot, there are lots of time spent waiting for filesystem jobs example: mounting, fsck, quota, quotoACL etc.
Only after this, the kernel will start the actual services. To reduce this time spent, systemd will setup an autofs mount and start the service.
when the filesystem finishes the quota etc it will replace by the real mount. This cannot be done for the filesystem like /,/proc where the service binaries are stored.
How daemon escapes init by double forking
Double forking is meant to make a process orphan and making it as a child for init process(PID 1). By this way, we can daemonize a process.
By double forking a process, it’s difficult to identify how the process is originally spawned in SysV. But systemd uses the Cgroups to keep track of the process.
For full application servers like apache which usually spawn many child processes, it is difficult to kill the entire service. Killing the apache process sometimes will not kill all its child process.Here systemd comes to rescue which uses systemctl to easily kill all process of a service.
vikki@trinity:~$ systemctl kill httpd.service
Cgroups also keeps track of cpu/mem utilzation of each process. To see Cgroups cpu/memory details
vikki@trinity:~$ systemd-cgtop Control Group Tasks %CPU Memory Input/s Output/s / – 12.6 3.4G – – /init.scope 1 – – – – /system.slice 43 – – – – /user.slice 546 – – – – /user.slice/user-1000.slice 546 – – – –
To recursively see Cgroups contents
vikki@trinity:~$ systemd-cgls Control group /: -.slice ├─init.scope │ └─1 /sbin/init splash ├─system.slice │ ├─avahi-daemon.service │ │ ├─1015 avahi-daemon: running [trinity.local │ │ └─1040 avahi-daemon: chroot helpe │ ├─thermald.service │ │ └─953 /usr/sbin/thermald –no-daemon –dbus-enable │ ├─dbus.service │ │ ├─ 970 /usr/bin/dbus-daemon –system –address=systemd: –nofork –nopidfile –systemd-activation │ │ └─2530 /usr/lib/x86_64-linux-gnu/fwupd/fwupd │ ├─uuidd.service │ │ └─2651 /usr/sbin/uuidd –socket-activation │ ├─ModemManager.service │ │ └─967 /usr/sbin/ModemManager │ ├─cron.service │ │ └─1004 /usr/sbin/cron -f │ ├─wpa_supplicant.service │ │ └─1218 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant │ ├─lightdm.service │ │ ├─1190 /usr/sbin/lightdm │ │ └─1268 /usr/lib/xorg/Xorg -core :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch │ ├─accounts-daemon.service │ │ └─1014 /usr/lib/accountsservice/accounts-daemon
To see the time spent in system startup
vikki@trinity:~$/usr/lib/systemd/network$ systemd-analyze time Startup finished in 6.503s (kernel) + 11.296s (userspace) = 17.799s
To see the time spent by each process during startup
vikki@trinity:~$/usr/lib/systemd/network$ systemd-analyze blame 7.985s firstname.lastname@example.org 2.450s dev-sda1.device 2.149s mysql.service 1.858s vmware-tools-thinprint.service 1.630s vmware-tools.service
Comparison of different init system:
sysvinit Upstart systemd Interfacing via D-Bus no yes yes Shell-free bootup no no yes Modular C coded early boot services included no no yes Read-Ahead no no yes Socket-based Activation no no yes Socket-based Activation: inetd compatibility no no yes Bus-based Activation no no yes Device-based Activation no no yes Configuration of device dependencies with Udev rules no no yes Path-based Activation (inotify) no no yes Timer-based Activation no no yes Mount handling no no yes fsck handling no no yes Quota handling no no yes Automount handling no no yes Swap handling no no yes Snapshotting of system state no no yes XDG_RUNTIME_DIR Support no no yes Optionally kills remaining processes of users logging out no no yes Linux Control Groups Integration no no yes Audit record generation for started services no no yes SELinux integration no no yes PAM integration no no yes Encrypted hard disk handling (LUKS) no no yes SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agents no no yes Network Loopback device handling no no yes binfmt_misc handling no no yes System-wide locale handling no no yes Console and keyboard setup no no yes Infrastructure for creating, removing, cleaning up of temporary and volatile files no no yes Handling for /proc/sys sysctl no no yes Plymouth integration no yes yes Save/restore random seed no no yes Static loading of kernel modules no no yes Automatic serial console handling no no yes Unique Machine ID handling no no yes Dynamic host name and machine meta data handling no no yes Reliable termination of services no no yes Early boot /dev/log logging no no yes Minimal kmsg-based Syslog daemon for embedded use no no yes Respawning on service crash without losing connectivity no no yes Gapless service upgrades no no yes Graphical UI no no yes Built-In Profiling and Tools no no yes Instantiated services no yes yes PolicyKit integration no no yes Remote access/Cluster support built into client tools no no yes Can list all processes of a service no no yes Can identify service of a process no no yes Automatic per-service CPU cgroups to even out CPU usage between them no no yes Automatic per-user cgroups no no yes SysV compatibility yes yes yes SysV services controllable like native services yes no yes SysV-compatible /dev/initctl yes no yes Reexecution with full serialization of state yes no yes Interactive boot-up no no yes Container support (as advanced chroot() replacement) no no yes Dependency-based bootup no no yes Disabling of services without editing files yes no yes Masking of services without editing files no no yes Robust system shutdown within PID 1 no no yes Built-in kexec support no no yes Dynamic service generation no no yes Upstream support in various other OS components yes no yes Service files compatible between distributions no no yes Signal delivery to services no no yes Reliable termination of user sessions before shutdown no no yes utmp/wtmp support yes yes yes Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools no no yes