Init and init in linux

Differences between /init and /sbin/init

In Linux boot order, the kernel will execute /sbin/init , however, I can see another file /init existing in the file system on my linux (CentOS 8 WSL2, Ubuntu 20 WSL2). They are different binaries:

$ diff /init /sbin/init Binary files /init and /sbin/init differ 

2 Answers 2

/usr/sbin/init or /sbin/init is the executable starting the SysV initialization system. For compatibility reason, when systemd is installed, it’s an alias to an executable of the systemd world.

The executable /init is unusual, in a Linux system. I suggest to investigate the reasons why it’s present. It could be the part of a malware.

You’re right that it’s unusual to find /init on the rootfs, however, it would be completely normal to find one inside an initramfs.

@Claude /init, it’s in the official Ubuntu WSL2, downloaded as default from Windows Store. Shouldn’t be an issue. However, i guess /init is used by kernel instead of /sbin/init—>/lib/systemd/systemd, and I can’t use systemctl

You mentioned WSL 2. Microsoft still runs special Linux kernel inside VM and because the goal is not to strictly emulate they introduced own custom init process: like what’s the point to start cron/cups/X/etc in every distro you installed.

Microsoft altered init process to avoid useless resource consumption (according to expected use cases of WSL 2).

When you import a Linux distro image Microsoft adds own file /init which is shared among all distros!

Even more: according to How does WSL/WSL2/WSLg work without systemd? WSL 2 is utilizing a single VM to run all distros. So the kernel is the same and the instance of the kernel in memory is shared, separation is done though Linux namespaces.

Источник

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 the difference between /etc/init/ and /etc/init.d/?

What is the difference between /etc/init/ and /etc/init.d/ ? More generally, what meaning does the .d suffix convey to a directory?

3 Answers 3

/etc/init.d contains scripts used by the System V init tools (SysVinit). This is the traditional service management package for Linux, containing the init program (the first process that is run when the kernel has finished initializing¹) as well as some infrastructure to start and stop services and configure them. Specifically, files in /etc/init.d are shell scripts that respond to start , stop , restart , and (when supported) reload commands to manage a particular service. These scripts can be invoked directly or (most commonly) via some other trigger (typically the presence of a symbolic link in /etc/rc?.d/ ).

/etc/init contains configuration files used by Upstart. Upstart is a young service management package championed by Ubuntu. Files in /etc/init are configuration files telling Upstart how and when to start , stop , reload the configuration, or query the status of a service. As of lucid, Ubuntu is transitioning from SysVinit to Upstart, which explains why many services come with SysVinit scripts even though Upstart configuration files are preferred. In fact, the SysVinit scripts are processed by a compatibility layer in Upstart.

.d in directory names typically indicates a directory containing many configuration files or scripts for a particular situation (e.g. /etc/apt/sources.list.d contains files that are concatenated to make a virtual sources.list ; /etc/network/if-up.d contains scripts that are executed when a network interface is activated). This structure is usually used when each entry in the directory is provided by a different source, so that each package can deposit its own plug-in without having to parse a single configuration file to reference itself. In this case, it just happens that “init” is a logical name for the directory, SysVinit came first and used init.d , and Upstart used plain init for a directory with a similar purpose (it would have been more “mainstream”, and perhaps less arrogant, if they’d used /etc/upstart.d instead).

Источник