DevOps / Sys Admin Q & A #17 : Linux startup process

If we want to be good at troubleshooting, it's important that we understand how linux systems work.

The starting point, of course, is to know the startup process.

The first step of the boot process is the BIOS (Basic Input Output System).

The BIOS initializes hardware, including detecting hard drives, USB disks, CD-ROMs, network cards, and any other hardware.

The BIOS will then step through each boot device based on the boot device order it is configured to follow until it finds one it can successfully boot from.

In the case of a Linux server, that usually means reading the MBR (master boot record: the first 512 bytes on a hard drive) and loading and executing the boot code inside the MBR to start the boot process.

Picture credit: Basics of the Linux Boot Process

After the BIOS initializes the hardware and finds the first device to boot, the boot loader takes over.

The following list shows the boot loader depending on the device from a boot starts:

1. GRUB : boot from a hard drive
2. syslinux : boot from a USB
3. isolinux : boot from a CD-ROM
4. pxelinux : boot from a network

Once we select a particular kernel in GRUB, GRUB will load the Linux kernel into RAM and execute it.

Usually GRUB will also load an initrd (initial RAM disk) along with the kernel.

The initrd (initial RAM disk) has some crucial configuration files, kernel modules, and programs that the kernel needs in order to find and mount the real root file system.

The final step is to execute the /sbin/init program, which takes over the rest of the boot process.

The /sbin/init program is the parent process of every program running on the system.

This process always has a PID of 1 and is responsible for starting the rest of the processes that make up a running Linux system.

Here is the list of how we initialize a NIX OS:

1. System V init such as runlevels and /etc/rc?.d directories - the init process reads a configuration file called /etc/inittab to discover its default runlevel. It then enters that runlevel and starts processes that have been configured to run at that runlevel.
   
   1. Debian 6 and earlier
   2. Ubuntu 9.04 and earlier
   3. CentOS 5 and earlier


2. Upstart - Upstart was designed not only to address some of the shortcomings of the System V init process, but also to provide a more robust system for managing services.
   One main feature of Upstart is that it is event-driven. Upstart constantly monitors the system for certain events to occur, and when they do, Upstart can be configured to take action based on those events.
   Upstart scripts reside in /etc/init.
   
   1. Ubuntu 9.10 to Ubuntu 14.10, including Ubuntu 14.04
   2. CentOS 6


3. systemd is the init system for the most recent distributions:
   
   1. Debian 7 and Debian 8
   2. Ubuntu 15.04 -
   3. CentOS 7 -

How to list services that run on startup?

Upstart:

$ initctl list

To list all Upstart services and run initctl show-config on them, this one-liner may be helpful:

$initctl list | awk '{ print $1 }' | xargs -n1 initctl show-config

System V

$ service --status-all

For init scripts:

$ ls /etc/init.d/

For runlevel symlinks:

$ ls /etc/rc*.d/

SystemD (How To Use Systemctl to Manage Systemd Services and Units)

To list all services:

$ systemctl list-unit-files --type=service

$ ls /lib/systemd/system/*.service /etc/systemd/system/*.service

1. cat /etc/*-release
2. cat /etc/issue
3. cat /proc/version
4. lsb_release -a
5. uname -a

/proc is very unique in that it is not a real filesystem. It's sometimes referred to as a process information pseudo-file system. It doesn't contain 'real' files but runtime system information (e.g. system memory, devices mounted, hardware configuration, etc).

For this reason it can be regarded as a control and information center for the kernel. In fact, quite a lot of system utilities are simply calls to files in this directory.

For example, lsmod is the same as 'cat /proc/modules' while lspci is a synonym for 'cat /proc/pci'.

The most weird thing about files in this directory is the fact that all of them have a file size of 0, with the exception of "kcore" and "self".

The directory listing looks similar to the following:

total 0
dr-xr-xr-x  9 root            root                     0 Apr 21 17:29 1
dr-xr-xr-x  9 root            root                     0 May  4 15:57 10
dr-xr-xr-x  9 postgres        postgres                 0 May  4 15:24 1007
dr-xr-xr-x  9 k               k                        0 May  4 15:24 10717
dr-xr-xr-x  9 k               k                        0 May  4 15:24 12288
dr-xr-xr-x  9 root            root                     0 May  4 15:57 123
dr-xr-xr-x  9 nobody          dip                      0 May  4 15:24 1269
dr-xr-xr-x  9 k               k                        0 May  4 15:24 13799
dr-xr-xr-x  9 ntp             ntp                      0 May  4 15:24 1401
dr-xr-xr-x  9 mysql           mysql                    0 May  4 15:24 14747
-r--------  1 root            root       140737477881856 May  4 16:04 kcore
lrwxrwxrwx  1 root          root                       11 May  4 16:06 mounts -> self/mounts

We may wonder how we can see details of a process that has a file size of 0. It makes more sense if we think of it as a window into the kernel. The file doesn't actually contain any data; it just acts as a pointer to where the actual process information resides.

Check Linux Filesystem Hierarchy

DevOps

DevOps / Sys Admin Q & A