Linux: What is the init process in linux?

Init

Init is an abbreviation for initialization. It is the first process that runs once the system boots up, with a PID of 1. All processes are initiated by Init. Its primary function is to execute scripts written in the file /etc/inittab.  It manages the independent operations necessary for any given system.

After reading this file, init determines how the system should be configured in each runlevel and also sets the default runlevel. After defining the system’s default runlevel, Init launches all background processes. In Linux, there are three primary init implementations: System V, Upstart, and systemd. In this section we will go deeper into these three implementations.

Overview of System V

If you have /etc/inittab  on your system, then it indicates that you are using system V implementation init.

Processes are started and stopped sequentially by Sys V. As a result, you must ensure that a service named random-1 is already running before starting random-2. Sys V manages this through scripts that offer us instructions on how to start and stop services. We can write our own scripts, but we usually utilize the ones that come with the operating system and are used to load vital services.

The benefits of utilizing this implementation of init are that it is reasonably straightforward to handle dependencies because you know random-1 comes before random-2, but performance isn’t great because only one item is normally beginning or stopping at a time.

The machine’s state is determined by runlevels, which range from 0 to 6. The information regarding these runlevels is provided below.

During boot, it checks to see what runlevel you are in and executes scripts included within that runlevel configuration. The scripts may be found in  /etc/rc.d/rc[runlevel number].d/ or /etc/init.d. Scripts that begin with S(start) or K(kill) will be executed at startup and shutdown, respectively. The numbers next to these characters represent the order in which they appear.

Service of System V

There are many commands that exist to manage the sys V services. You can see the available services by running the command line in the terminal.

$ service --status-all

To start a service,

$ sudo service networking start

To stop a service,

$ sudo service networking stop

To restart a service,

$ sudo service networking restart

These commands are not specifically built for sys V. You can use these to handle upstart services also. 

One thing to note here is that System V is losing popularity. Linux is attempting to replace the current V init with another init implementation. There is a chance that alternative init implementations will appear in the future.

Overview of Upstart

If you have  /usr/share/upstart directory on your system, then chances are that you are using upstart implementation. 

Canonical was the creator of Upstart. So it was the init implementation on Ubuntu for a while, however, systemd is now used on recent Ubuntu systems. Upstart was developed to address issues with Sys V, such as the rigorous starting processes, task blocking, and so on. Upstart’s event and task-driven models enable it to react to events as they occur.

Actions that upstart performs are known as jobs and the messages for triggering a job are known as events. It begins by loading the job settings from /etc/init.d. When a startup event happens, the jobs that are prompted by that event are executed. These jobs will generate new events, which will in turn generate additional jobs. Upstart will keep doing this until it has completed all of the required tasks. To see the jobs and their configuration let’s run the command below.

$ ls /etc/init

Inside these job configurations, it’ll include information on how to start jobs and when to start jobs. Let’s see inside the conf file.

There are many ways to write the configuration file and you’ll discover that when you look at the different job configurations available.

Upstart Jobs

Unfortunately, there is no simple method to determine the source of an event or job, so you’ll have to tinker with the job parameters in /etc/init. Upstart can cause a lot of events and jobs to execute. Most of the time, you won’t ever need to check the Upstart job configuration files, but you may wish to more easily manage some particular jobs. In an Upstart system, you may utilize a variety of helpful commands. To see the list of jobs of upstart you have to run the following command.

$ initctl list

To view a specific job,

$ initctl status networking

To start a job,

$ sudo initctl start networking

To stop a job,

$ sudo initctl stop networking

To restart a job,

$ sudo initctl restart networking

To emit an event,

$ sudo initctl emit some_event

Overview of systemd

If you have /usr/lib/systemd directory on your system, then most likely you are using systemd. It is getting more and more popular over time. 

There are 12 different sorts of “units” that systemd offers a dependency system between. Units contain a variety of items important for system boot-up and maintenance. To get your system operating, Systemd employs goals. In essence, you have a goal you wish to accomplish, and this goal also has dependencies we must meet. Systemd is much more efficient than other init implementations as it does not require a stern sequence. 

Now, let’s discuss the boot process for the systemd. Systemd loads the configuration files initially which are often located in the /etc/systemd/system or /usr/lib/systemd/system directory. From there, it can set the boot target to achieve which is normally target.default. After that, it resolves the dependencies for the boot target and activates them. In this way, systemd completes its goal. Systemd boots into a separate target, much as system V runlevels.

• poweroff.target : shutdown system
• rescue.target : single user mode
• multi-user.target : multiuser with networking
• graphical.target : multiuser with networking and GUI
• reboot.target : restart

Because of its flexibility, Systemd can operate a variety of various sorts of units, including filesystems, network sockets, and more than simply services. When we activate one unit, everything below it is also activated, for instance, if we boot into our default.target, which groups together the networking.service unit, crond.service unit, etc.

Goals of Systemd

In this part, we will briefly discuss how we can manually control units. Run the command below to check the units on your system.

$ systemctl list-units

To view the status of a unit,

$ systemctl status networking.service

To start a service,

$ sudo systemctl start networking.service

To stop a service,

$ sudo systemctl stop networking.service

To restart a service,

$ sudo systemctl restart networking.service

To enable a unit,

$ sudo systemctl enable networking.service

To disable a unit,

$ sudo systemctl disable networking.service

Power States

In this part, we will see how we can shut down the system using the command line. 

To shut down the system immediately,

$ sudo shutdown -h now

Here, the ‘-h’ flag denotes halt or power off of the system. Now indicates the time value. You can select the time as you like.

$ sudo shutdown -h +5

The system will take five minutes to shut down.

To restart the system,

$ sudo shutdown -r now

The ‘-r’ flag indicates the restart operation.  You can also restart the system by using the command below.

$ sudo reboot