Linux init services - Linux Tutorial

- [Instructor] The original Init system that Linux used, came from Unix. In this system there was shell script running as process ID number one, that would start other shell scripts to start the system. If the execution of one script was delayed, the entire boot process had to wait for it to finish. Later, runlevels were introduce with Unix System V. This allowed administrators to switch into different states, or runlevels. Even the process of rebooting and shutting down was handled by runlevel. There was a runlevel for maintenance. One for a host without a GUI, and one for a host with a GUI, along with a couple of extra runlevels that could modified. The default runlevel was configured in /etc/inittab. All Init scripts were held in /etc/init.d. There were also directories in /etc/rc.d. And these directories were symbolic links to the actual Init scripts in /etc/init.d. There was one directory for each runlevel such as /etc/rc.d/rc5.d for runlevel five. Starting and stopping services, and even the execution order was determined by the link name. This made the name of the symbolic link very important. Services to be started on a runlevel had names starting with a S. The order was determined by the name. A link name S10network would start before link name S12rsyslog. To make rsyslog start before the network, you'd just rename the link. Link names starting with a K were services that were killed when entering a runlevel. The problem with the System V Init system was the same. It unintelligent and synchronous. This was fine for a server that rebooted once per year, but Linux was being used for more and more different devices, including workstations, dynamic cloud clients, mobile devices, and embedded systems where boot up time was important. Red Hat Enterprise Linux used System V Init for the first eight years of its existence. They switched to Upstart with RHEL 6, and then Systemd with RHEL 7. Upstart offered asynchronous service startup, automatic restart of crash services, and event-based starting of services. An event could be a change in hardware, or it could be triggered by a process, or the starting of another service. Upstart sped up system booting, and made the initialization process much more intelligent. It still relied on the etc Init tab file to determine the default runlevel, and use shell scripts in runlevel directories. Wanting to go the the next level, Red Hat switched to Systemd for RHEL 7. Systemd is a powerful, but sometimes bewildering initialization system. It supports parallel processing of startup scripts, service dependencies, on-demand activation of services using sockets and D-Bus, snap shotting system states, process tracking using control groups. Parallel mounting and checking of file systems, and lastly, binary optimization of startup programs. Systemd handles on-demand activation of service by creating a socket, and handing it to the service when it's executed. This allows for a service to begin accepting data before it even starts. This is useful because services can remain off until they're requested. It also means that if a service has a dependency on another service, the dependency doesn't need to start until it's needed. Systemd can be complex, but is indeed very powerful.