Systemd's aim was to eliminate differences in how services are managed across various Linux distributions. It's currently the main init and system manager across several Linux distributions over CSV init. Systemd is now the first process that is started by the kernel and it has a process ID of one. You can verify this by running the top minus p, 1 minus n, 1 command in your systems. Systemd is the reason why some of the older Linux distributions have changed the way services are managed. A few years ago you may have seen commands like service example restart on Rail 6. After systemd was implemented, say on Fedora 15, first new at Rail distributions later, the same result can be achieved by running the systemctl restart example command. The systemctl command is one of the large set of commands that systemd brought to Linux. Now, remember slash etc, slash any tab, that file is no more. Instead we have a slash etc, slash systemd, slash system directory which contains siblings to files in slash user, slash lib, slash systemd, slash system. Now, that folder contains init scripts, that is, to start a service, at boot, it must be linked to slash etc, slash systemd system. The systemctl enable command does this for you when you enable a new service. Now, here are some of the benefits of systemd. Some of these are self-explanatory. So for example, systemd does parallel execution of initial scripts that need to run at boot time, therefore, it helps you boot faster than the older SysVinit. Systemd also offers the ability to start device on-demand. This means that services are started when needed rather than lots of service has been started at boot time reducing boot time overall. System resources are also not consumed if that service is not started at boot time unnecessarily. Finally it can work as a drop-in replacement of SysVinit. Here are the various components of systemd. Let's start with the systemd utilities. These are, first, systemctl. This is the central management tool for controlling the system. You can manage services, check statuses, change systems statuses, and work with system configuration files using systemctl. Then journalctl, this is a utility for querying and displaying logs from journald systems d, logging service. Since generald stores log data in a binary format instead of a plain text format, journalctl is the standard way of reading log messages processed by journald. Now, notify, this may be called by demo scripts to notify the init system about status changes. It can be used to send arbitrary information encoded in an environment block-like a list of strings. Then there's analyze. This may be used to determine system boot up performance statistics and retrieve other state and tracing information from the system and service manager and to verify the correctness of unit files. Then there's cgls. This is used to view the hierarchy of control groups or cgroups. A cgroup is a collection of processes that are bound by these same criteria and association with a set of parameters or limits. These groups can be hierarchical, meaning that each group inherits limits from its parents group. Please try executing the command systemd minus cgls in your lab system to view the hierarchy. Then there's cgtop. This shows the top control groups of the local Linux control group hierarchy ordered by the CPU memory or disk I/O load. Then loginctl. This may be used to introspect and control the state of the systemd login manager called the systemd minus logid.service. Finally, nspawn. An s stands for namespace, so nspawn stands for namespaces spawn. This is used to create isolated environments, so it's helpful in creating a container like environment. But unlike docker containers, systemd and spawn does not have a special image repository, but there are ways of overcoming that which we're not going to get into here. Now, we've only covered the utilities here. In upcoming videos, we'll slowly get accustomed to other concepts and ideas through the rest of this module.
