Mastering Linux System Administration. Richard Blum

The SysVinit initialization method used a concept called runlevels to determine what processes to start. The runlevel defines the state of the running Linux system and what processes should run in each state. Table 1.1 shows the different runlevels associated with the SysVinit initialization method.

TABLE 1.1: The SysVinit Runlevels

RUNLEVEL	DESCRIPTION
0	Shuts down the system
1	Single‐user mode used for system maintenance
2	Multiuser mode without networking services enabled
3	Multiuser mode with networking services enabled
4	Custom
5	Multiuser mode with GUI available
6	Reboots the system

      The /etc/inittab file defines the default runlevel for a system. The processes that start for specific runlevels are defined in subdirectories of the /etc/rc.d directory. You can view the current runlevel at any time using the runlevel command, as shown here:

      $ runlevel N 5 $

      The systemd initialization method became popular because it has the ability to start processes based on different events such as these:

       When the system boots

       When a particular hardware device is connected

       When a service is started

       When a network connection is established

       When a timer has expired

The systemd method determines what processes to run by linking events to unit files. Each unit file defines the programs to start when the specified event occurs. The systemctl program allows you to start, stop, and list the unit files currently running on the system.

      The systemd method groups unit files together into targets. A target defines a specific running state of the Linux system, similar to the SysVinit runlevel concept. At system startup, the default.target unit defines all the unit files to start. You can view the current default target using the systemctl command.

      $ systemctl get-default graphical.target $

      The graphical.target target defines the processes to start when a multiuser graphical environment is running, similar to the old SysVinit runlevel 5.

       Real World Scenario

      EXAMINING PROCESSES

      In Chapter 14, “Working with Processes and Jobs,” you'll see how to use the ps command to view the processes currently running on the Linux system. You can use it now to take a quick peek at what programs are currently running on your Linux system.

      1 Log into your Linux system. (If you don't have a Linux system available yet, you can come back to here after going through either Chapter 2 or Chapter 4.)

      2 At the command prompt, enter the command psax. You should see something similar to this output:$ ps ax PID TTY STAT TIME COMMAND 1 ? Ss 0:00 /sbin/init maybe-ubiquity 2 ? S 0:00 [kthreadd] 3 ? I< 0:00 [rcu_gp] 4 ? I< 0:00 [rcu_par_gp] 5 ? I 0:00 [kworker/0:0-memcg_kmem_cache] 6 ? I< 0:00 [kworker/0:0H-kblockd] 7 ? I 0:00 [kworker/0:1-events] 8 ? I 0:00 [kworker/u2:0-events_power_efficient] . . . 1033 tty1 S 0:00 -bash 1054 tty1 R+ 0:00 ps ax $We've just shown the start of the listing, along with the last two lines, but you should see a long list of different programs running on your Linux system (including the ps command that you started). The kernel is keeping track of all those programs!

      HARDWARE MANAGEMENT

      Still another responsibility for the kernel is hardware management. Any device that the Linux system must communicate with needs driver code inserted inside the kernel code. The driver code allows the kernel to pass data back and forth to the device, acting as a middleman between applications and the hardware. There are two methods used for inserting device driver code in the Linux kernel.

       Drivers compiled in the kernel

       Driver modules added to the kernel

      Previously, the only way to insert device driver code was to recompile the kernel. Each time you added a new device to the system, you had to recompile the kernel code. This process became even more inefficient as Linux kernels supported more hardware. Fortunately, Linux developers devised a better method to insert driver code into the running kernel.

      Programmers developed the concept of kernel modules to allow you to insert driver code into a running kernel without having to recompile the kernel. Also, a kernel module could be removed from the kernel when the device was finished being used. This greatly simplified and expanded using hardware with Linux.

      The Linux system identifies hardware devices as special files, called device files. There are three different classifications of device files.

       Character

       Block

       Network

      Character device files are for devices that can only handle data one character at a time. Most types of modems and terminals are created as character files. Block files are for devices that can handle data in large blocks at a time, such as disk drives.

      The network file types are used for devices that use packets to send and receive data. This includes network cards and a special loopback device that allows the Linux system to communicate with itself using common network programming protocols.

      Linux creates special files, called nodes, for each device on the system. All communication with the device is performed through the device node. Each node has a unique number pair that identifies it to the Linux kernel. The number pair includes a major and a minor device number. Similar devices are grouped into the same major device number. The minor device number is used to identify a specific device within the major device group.

      FILESYSTEM MANAGEMENT

Unlike some other operating systems, the Linux kernel can support different types of filesystems to read and write data to and from hard drives. Besides having more than a dozen filesystems of its own, Linux can read and write to and from filesystems used by other operating systems, such as Microsoft Windows. The kernel must be compiled with support for all types of filesystems that the system will use. Table 1.2 lists the standard filesystems that a Linux system can use to read and write data.

TABLE 1.2: