Run init process linux

Init process on UNIX and Linux systems

Init is the parent of all processes, executed by the kernel during the booting of a system. Its principle role is to create processes from a script stored in the file /etc/inittab. It usually has entries which cause init to spawn gettys on each line that users can log in. It controls autonomous processes required by any particular system.

After reading this file, how the system should be set up in each runlevel is determined by init and also set default runlevel. Init starts all background process after setting default runlevel for the system.

Runlevels

Runlevel, a software configuration of the system which allows only a selected group of processes to exist. The processes produced by init for each of these runlevels are defined in the /etc/inittab file.

Init can be in one of these eight runlevels: 0-6 and S or s. The runlevel can be changed by having a privileged user run telinit, which sends appropriate signals to init, telling it which runlevel to change to.

Booting

After invoking init as the last step of the kernel boot sequence, it sees if an entry of the type initdefault is present in the file /etc/inittab. The initdefault entry determines the initial runlevel of the system. If no such entry (or no /etc/inittab at all) is present there, a runlevel must be entered at the system console.

Changing Runlevels

After specifying all the processes, init waits for one of its descendant processes to die, a powerfail signal, or until it is signaled by telinit to change the system’s runlevel. It re-examines the /etc/inittab file, when one of the above three conditions occurs.

init still waits for one of the above three conditions to occur. For providing an instantaneous response, the telinit Q or q command can wake up init to re-examine the/etc/inittab file.

If init is not in single user mode and receives a powerfail signal (SIGPWR), it reads the file /etc/powerstatus. Then it starts a command based on the contents of this file −

Tag	Description
F(AIL)	Power is failing, UPS is providing the power. Execute the powerwait and powerfail entries.
O(K)	Power has been restored, execute the powerokwait entries.
L(OW)	The power is failing and the UPS has a low battery. Execute the powerfailnow entries.

If /etc/powerstatus contains anything else then the letters F, O or L or doesn’t exist, init will behave as if it has read the letter F.

Usage of SIGPWR and /etc/powerstatus is discouraged. If Someone wanting to interact with init should use the /dev/initctl control channel — see the source code of the sysvinit package for more documentation about this.

When init is requested to change the runlevel, it sends the warning signal SIGTERM to all processes that are undefined in the new runlevel. Then It waits 5 seconds before forcibly terminating these processes via the SIGKILL signal.

Init assumes that all these processes and their descendants remain in the same process group which init originally created for them. It will not receive these signals, if any process changes its process group affiliation. Such processes need to be terminated separately.

TELINIT

/sbin/telinit is linked to /sbin/init which takes a one-character argument and signals init to perform the appropriate action. The following arguments serve as directives to telinit −

Tag	Description
0,1,2,3,4,5 or 6	tell init to switch to the specified run level.
a, b, c	tell init to process only those /etc/inittab file entries having runlevel a, b or c.
Q or q	tell init to re-examine the /etc/inittab file.
S or s	tell init to switch to single user mode.
U or u	tell init to re-execute itself (preserving the state). No re-examining of/etc/inittab file happens. Request would be silently ignored, if Run level is not one of Ss12345.

It can also tell init how long it should wait between sending processes the SIGTERM and SIGKILL signals. 5 seconds is the default, but this can be changed with the -t sec option.

Only by users with appropriate privileges can invoke telinit.

By looking at its process id, init binary checks if it is init or telinit; the real init’s process id is always 1. So, instead of calling telinit one can also just use init instead as a shortcut.

Источник

init

Warning: Arch Linux only has official support for systemd. [1] When using a different init system, please mention so in support requests.

Init is the first process started during system boot. It is a daemon process that continues running until the system is shut down. Init is the direct or indirect ancestor of all other processes, and automatically adopts all orphaned processes. It is started by the kernel using a hard-coded filename; if the kernel is unable to start it, panic will result. Init is typically assigned process identifier 1.

The init scripts (or rc) are launched by the init process to guarantee basic functionality on system start and shutdown. This includes (un)mounting of file systems and launching of daemons. A service manager takes this one step further by providing active control over launched processes, or process supervision. An example is to monitor for crashes and restart processes accordingly.

These components combine to the init system. Some inits include the service manager in the init process, or have init scripts in close relation to them. These inits are below referred to as integrated, though entries in different categories may explicitly depend on each other.

Inits (integrated)

• anopa — Init system built around the s6 supervision suite.

• GNU Shepherd — Init system written in Guile.

• OpenRC — Dependency-based init system.

• systemd — Dependency-based init system with aggressive parallelization, process supervision using cgroups, and the ability to depend on a given mount point or dbus service.

Inits

• BusyBox — Utilities for rescue and embedded systems.

• sinit — Simple init initially based on Rich Felker’s minimal init.

• SysVinit — Traditional System V init.

Init scripts

• initscripts-fork — Maintained fork of SysVinit scripts in Arch Linux.

• minirc — Minimal init script designed for BusyBox.

• kisslinux-init — Init framework of KISS Linux.

Service managers

• Monit — Monit is a process supervision tool for Unix and Linux. With monit, system status can be viewed directly from the command line, or via the native HTTP(S) web server.

• perp — Persistent process (service) supervisor and management framework for UNIX.

• runit — UNIX init scheme with service supervision, a replacement for SysVinit, and other init schemes.

• s6 — Small suite of programs for UNIX, designed to allow service supervision in the line of daemontools and runit.

• Supervisor — A system that allows its users to monitor and control processes on UNIX-like operating systems.

Configuration

Migrate running services

To run daemons under the new init, save a list of running daemons:

$ systemctl list-units --state=running "*.service" > daemons.list

and configure the #Init scripts accordingly. See also [2].

logind

logind requires systemd to be the init process. [3] As such, local sessions and other functionality is not available.

Device permissions

Add users to respective user groups for device access and reboot. Current group membership should first be checked with id user .

# usermod -a -G video,audio,power,disk,storage,optical,lp,scanner,input user 

Rootless X

As Xorg.wrap does not check if logind is active [5], root rights for Xorg need be enabled manually.

Power management

Scheduled tasks

Arch uses timer files instead of cron by default. See archlinux-cronjobs for basic cron jobs.

Dbus

This article or section needs expansion.

User instances of dbus-daemon are launched by systemd/User [6]. When requiring IPC between desktop applications, restore 30-dbus.sh :

/etc/X11/xinit/xinitrc.d/30-dbus.sh

#!/bin/bash # launches a session dbus instance if [ -z "$" ] && type dbus-launch >/dev/null; then eval $(dbus-launch --sh-syntax --exit-with-session) fi

Tips and tricks

systemd-nspawn

systemd-nspawn is a tool for systemd systems. Since Linux 2.6.19, it is possible, however, to run systemd on a non-systemd system by using PID namespace. For it, the kernel needs to be configured with CONFIG_PID_NS and CONFIG_NAMESPACES ).

The PID namespace creates a new hierarchy of processes starting with PID 1. In addition to this, systemd requires a chrooted root filesystem to be mounted. Hence, you have to at least make a bind mount, because otherwise some services will fail with

"Failed at step NAMESPACE spawning" due to "Invalid operation"

as systemd tries to remount the root with private option.

To setup a chroot with a new PID namespace, you can use jchroot.[7] [8]. Make sure not to mount /proc inside the new root before chrooting, otherwise systemd will detect the chroot environment. You can mount it later once systemd is running.

Replacing udev

Warning: Replacing udev is not required as systemd-udev is functional without systemd as PID 1. Some replacements such as eudev can also not coexist with systemd —ensure an alternative init is booted prior to their installation.

• eudev — eudev is a fork of udev started by the Gentoo project. It is primarily designed and tested with OpenRC.

• mdev — Device manager for usage in embedded systems.

• smdev — smdev is a simple program to manage device nodes. It is mostly compatible with mdev but does not have all of its features.

See also

Источник

What is ‘init’ Process and Command in Linux?

In this article, you will learn about the short description of the init process, the runlevels of init, and the init command in a Linux system.

What is Init Process?

In layman’s terms, when you press the power button, your system will first look for the bootloader (basically, your Linux grub), and then it will try to launch the kernel.

But the kernel itself cannot launch all of the processes, so it will start the first (or parent) process, known as init (sort for “initialization“), with PID “1” (process identifiers are assigned in sequential order).

The “/etc/inittab” script is used by the “init” process. It has entries for processes that do basic things when the system starts up and shuts down, like showing the user a login screen with gettys, mounting and unmounting file systems, and managing daemons.

As a result, it should be kept running until the system terminates. If the kernel is unable to start it, the system will reach a stage called “Kernel Panic“.

Run Levels

Run Levels is a system software configuration (by init) that defines a set of processes to start when the system boots. The processes spawned by the init for each of these run levels are defined in the file “/etc/inittab“.

Run Levels are numbered from zero to six and define the state of the machine after boot, as listed below.

Run Levels	Mode	Functions
0	Halt	Halt the system.
1	Single-User Mode	Get the system into single user mode.
2	Multi-User Mode	Get the system into multiuser mode without networking.
3	Multi-User Mode with Networking	Get the system into multiuser mode with networking.
4	Undefined	Not used
5	X11	Get the system into multiuser mode with networking and X windows.
6	Reboot	Reboot the system.

The majority of Linux systems is based on runlevel 3 or 5. Although, users can modify these runlevels or create new ones based on their requirements.

The 0, 1, and 6 are reserved runlevels used for halting, getting into single user mode, and rebooting the system.

Init Command in Linux

In most Linux systems, the init command is used to send control commands to the init daemons that run as background processes.

$ init [OPTION]

The following is a list of all known options, along with their descriptions.

Commands	Description
0	Shutdown the system.
6	Reboot the system.
2, 3, 4, 5	Start runlevelX.target unit.
1, s, S	Enter rescue mode.
q, Q	Reload the init daemon configuration.
u, U	Re-execute the init daemon.

Conclusion

There are numerous items that should be included, but the goal of this article is not to provide a detailed description of the init process or command; rather, it is to walk you through them.

If you are more interested in knowing the init process, then check this article, as this method of booting the system is deprecated with systemd, so there is no future plan to have a major update in this article.

If you are interested in learning about them from our site or want this article to be more concise, then do let me know in the comment section.

Источник