You have now been learning system management strategies, networking in Linux, and some software installation related features in IBM power systems. It's a nice achievement to reach this part of the curriculum, so well done. Now, I'd like to take you on a journey to meet a suite of software utilities that are used on all the Linux distributions to manage the various Linux system components. Before we talk about systemd, a quick overview of the traditional system initialization process on Linux. Before Red Hat Enterprise Linux version six, we used a startup manager called SysVinit, this is the same startup manager used in Unix systems as well. Now, you may ask, well, what's a startup manager? We described the Linux boot process in one of our previous units, here's a quick recap. After powering on and the handoff to the GRUB bootloader, the kernel and the initial RAM disk are loaded. Once the kernel has finished starting up, it will invoke a startup manager, SysVinit is one such startup manager. It was universally accepted before Red Hat Enterprise Linux version six and it was linear, meaning it started one process at a time one after another. You can already see its disadvantages, this could result in longer boot times as there may be a lot of services that needed to be started. You may see the term init used a lot in the Linux world, in this case, the kernel will start the first process in the system and it's called the init process, it gets the process ID of 1. If SysVinit is being used in a system, you can verify this by running the top command with the -p attribute set to 1 and the -n attribute set to 1 to quickly exit after returning the output, so the command to execute would be top -p 1 -n 1. In Red Hat Linux distributions, rc.sysinit is the first script that is executed by the init process. This script is meant to initialize the system and this includes the following, loading the kernel modules, setting the hostname, it configures kernel parameters from the sysctl.conf, initialize serial ports, RAID, LVM, checks and mounts file systems like a slash procs, slash sys, and others in slash etc slash fstab. This is where it remounts the root file system with the options specified in slash etc slash fstab. And note that the root file system will be mounted at sys.route as read only by the kernel before the init process starts. After rc.sysinit executes, the runlevel scripts will then execute, these are the scripts inside slash etc slash rc.d. If the run default level is set to 3, then these scripts under rc3.d will be executed and so forth. After the runlevel scripts are done executing the slash etc slash rc.d, slash rc.local script will then execute. And this file is where you put extra startup stuff if you don't want to do the whole sys.d script stuff, which involves creating symlinks and naming your scripts in a specific format and so forth. Now, most Linux and Unix sysadmins know how to properly add both kill and start scripts to the appropriate slash etc slash rc2.d or rc3.d and so on, depending upon the runlevel directories to ensure that services are started in the appropriate run state. But they might not know exactly why adding a script to slash etc slash rc3.d or rc2.d has the effect that they want. Hopefully, we have thrown a little light on the Linux boot process and you can explore more from here. The concerns of serial execution in sysVinit led to the development of other startup managers. Some startup managers are Upstart, Epoch, Mudar which is written in Python, and systemd. [MUSIC]
