Выпуск системы инициализации sysvinit 2.92

Демоны и другие процессы

Система инициализации должна запускать все необходимые демоны, фоновые процессы и службы, которые требуются для корректного функционирования операционной системы. Примерами упомянутых процессов являются процессы, предназначенные для показа экрана загрузки системы, инициализации различных частей сетевого стека, а также аппаратного обеспечения вашей машины.

Чаще всего данные процессы продолжают работать в фоновом режиме после запуска и называются демонами. Эти демоны управляют многими механизмами вашей системы, такими, как механизм записи информации в системный журнал, механизм отслеживания событий подключения или отключения различных устройств, а также механизм обработки входов пользователей в систему.

Для того, чтобы увидеть список всех процессов и демонов, которыми управляет система инициализации systemd в рамках вашей системы Fedora, следует использовать команду в терминале.

После завершения инициализации системы система инициализации будет продолжать свою работу настолько долго, насколько долго будет функционировать ваша система, и при этом она будет осуществлять управление уже запущенными процессами, а также позволит запустить, остановить или перезапустить другие процессы в течение всего периода работы операционной системы.

inittab

In this section we examine common entries in inittab, in the same order as they appear in the default inittab used by Arch. After that there are a few examples to help you create your own inittab entry.

Warning: Always test a modified with before you reboot, or a small syntax error can prevent your system from booting.

Default Runlevel

The default runlevel is 3. Uncomment or add this if you prefer to boot into runlevel 5 (which is used for X conventionally) by default:

id:5:initdefault:

Main Boot Scripts

These are the main Arch init scripts.

rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown

Single User Boot

Sometimes your kernel may fail to boot up all the way, due to a corrupted or dead hard drive or filesystem, missing key files, etc. In that case your init image may automatically enter into single-user mode which only allows root login and uses instead of to control the login process. You can also boot into single-user mode by appending the letter to your kernel command line in your GRUB, LILO, or syslinux configuration. If you would like something other than sulogin to run, specify it here.

su:S:wait:/sbin/sulogin -p

Gettys and Login

These are crucial entries that run the gettys on your terminals. Most default configurations will have several gettys running on ttys1-6 which is what pops up on your screen with the login prompt. Also see openvt, chvt, stty, and ioctl.

c1:234:respawn:/sbin/agetty 9600 tty1 xterm-color
c5:5:respawn:/sbin/agetty 57600 tty2 xterm-256color

When the special key sequence is pressed, this determines what to do.

ca::ctrlaltdel:/sbin/shutdown -t3 -r now

X Programs

If you are not afraid to debug, you can figure out how to start all sorts of programs from inittab. One useful type of program is to start your login manager when the runlevel is 5, multi-user-x-mode. In the following example you can see how to start SLiM when entering runlevel 5.

x:5:respawn:/usr/bin/slim >/dev/null 2>&1
#x:5:respawn:/usr/bin/xdm -nodaemon -confi /etc/X11/xdm/archlinux/xdm-config

Power-Sensing Scripts

Init can communicate with your UPS device and execute processes based on the status of the UPS. Here are some examples:

pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"

Custom Keyboard Request

The following line adds a custom function for when a special key sequence is pressed. You can modify this special key sequence to be anything you like, similar to a .

kb::kbrequest:/usr/bin/wall "Keyboard Request -- edit /etc/inittab to customize"

Trigger the kbrequest

You can trigger the special key sequence kbrequest by sending the WINCH signal to the init process (1) as root (via sudo). In this example, the command:

kill -WINCH 1

Causes to write to all ttys:

Broadcast message from root@askapachehost (console) (Wed Oct 27 14:02:26 2010):
Keyboard Request -- edit /etc/inittab to customize

Уровни загрузки/цели

Systemd использует понятие целей(target), сходное по сути с уровнями загрузки, но работающее немного иначе. Каждая цель имеет название, описывающее её предназначение. Некоторые цели объединяют в себе запуск всех служб какой-то одной цели и нескольких дополнительных сервисов. Для замены уровней загрузки sysvinit были созданы специальные «цели», переключаться между которыми вы можете как и раньше используя команду . Стандартные для ROSA уровни загрузки 0, 1, 3, 5, и 6 полностью эквиваленты соответствующим целям systemd.

К сожалению, не существует простого способа реализовать пользовательские уровни 2 и 4. В качестве замены пользователь может создать новую цель /etc/systemd/system/$YOURTARGET на основе одной из имеющихся (в качестве примера посмотрите /lib/systemd/system/graphical.target), создать папку /etc/systemd/system/$YOURTARGET.wants, и с помощью символических ссылок добавить все необходимые вам дополнительные сервисы в эту папку. (Символические ссылки должны указывать на файлы служб *.service, расположенные в /lib/systemd/system).

Уровень загрузки sysvinit	Цель systemd	Комментарий
runlevel0.target, poweroff.target	Выключает систему.
1, s, single	runlevel1.target, rescue.target	Однопользовательский режим.
2, 4	runlevel2.target, runlevel4.target, multi-user.target	Уровни, определенные пользователем. По умолчанию эквивалентны уровню 3.
3	runlevel3.target, multi-user.target	Многопользовательский режим без графики.
5	runlevel5.target, graphical.target	Многопользовательский режим с графикой. Обычно эквивалентен запуску всех сервисов уровня 3 и графическому менеджеру входа.
6	runlevel6.target, reboot.target	Перезагрузка
emergency	emergency.target	Аварийная оболочка

Переключение уровня загрузки:

2. OpenRC

OpenRC — это система инициализации Linux и Unix подобных операционных систем совместимая с Sys V Init и поддерживающая систему зависимостей во время запуска. Она приносит некоторые улучшения в SysV, и как и другие системы инициализации Linux, совместима с ней, но вы должны иметь в виду, что OpenRC не заменяет полностью файл /sbin/init. Эта система инициализации используется в Gentoo и дистрибутивах BSD.

Кроме стандартных возможностей SysV, здесь поддерживается также:

• Поддержка зависимостей служб;
• Поддержка параллельного запуска служб;
• Поддерживает настройку в одном отдельном файле;
• Работает как демон;

По сравнению с SysV тут появилось много новых возможностей, но все еще не все те, что нужны для оптимальной работы системы.

Сервисы и службы

Команда sysvinit	Команда systemd	Комментарий
service frobozz start	systemctl start frobozz.service	Используется для разового запуска службы.
service frobozz stop	systemctl stop frobozz.service	Используется для разовой остановки службы.
service frobozz restart	systemctl restart frobozz.service	Используется для разового перезапуска службы.
service frobozz reload	systemctl reload frobozz.service	Если такая возможность поддерживается службой, перезагружает конфигурационный файл, не прерывая процесса.
service frobozz condrestart	systemctl condrestart frobozz.service	Перезапускает службу, если она запущена.
service frobozz status	systemctl status frobozz.service	Сообщает, запущена ли служба.
ls /etc/rc.d/init.d/	ls /lib/systemd/system/*.service /etc/systemd/system/*.service	Используется для получения списка служб, которые могут быть запущены или остановлены.
chkconfig frobozz on	systemctl enable frobozz.service	Включает запуск службы после перезагрузки.
chkconfig frobozz off	systemctl disable frobozz.service	Отключает запуск службы после перезагрузки.
chkconfig frobozz	systemctl is-enabled frobozz.service	Используется для проверки, будет ли служба запущена после перезагрузки.
chkconfig frobozz —list	ls /etc/systemd/system/*.wants/frobozz.service	Выдает список уровней загрузки(целей), при которых данная служба будет запущена автоматически.
chkconfig frobozz —add		Не используется, нет аналога.

Все вышеперечисленные команды /sbin/service и /sbin/chkconfig работают с systemd и автоматически переводятся в эквивалентные команды systemctl. Исключением является только chkconfig —list.

ПредупреждениеДополнительные команды Службы SysVinit могут иметь собственные дополнительные команды. Например, service iptables panic, или service httpd graceful. Сервисы systemd такой возможности не имеют. Каждый сервис решает эту проблему по-своему. Подробности ищите в документации и Release Notes соответствующего пакета.

3. Systemd

Systemd — это новая система инициализации Linux. Она была введена по умолчанию в Fedora 15, а сейчас используется почти во всех популярных Linux дистрибутивах. Это не только инициализирующий процесс, поддерживающий огромное количество возможностей, но и набор инструментов для управления службами и этими возможностями из системы. Основная цель — иметь полный контроль над всеми процессами во время их запуска и на протяжении всего выполнения.

Systemd очень сильно отличается от всех существующих систем инициализации, тем как она работает с сервисами, и даже конфигурационными файлами сервисов. Совместимости со скриптами SysV нет, их нужно преобразовать в linux systemd unit файлы.

Вот ее основные особенности:

• Понятный, простой и эффективный дизайн;
• Параллельная загрузка служб на основе зависимостей;
• Поддерживается завершение дополнительных процессов;
• Поддерживается собственный журнал с помощью journald;
• Поддерживается планирование заданий с помощью таймеров Systemd;
• Поддерживается управление сетью с помощью networkd;
• Для управления DNS используется systemd-resolved;
• Хранение журналов в бинарных файлах;
• Сохранение состояния сервисов linux systemd для возможного восстановления;
• Улучшенная интеграция с Gnome;
• Запуск сервисов по требованию;

Switching runlevel

Through bootloader

To change the runlevel the system boots into, simply add the desired runlevel to the respective bootloader’s configuration line. A common application of this is . To boot to the desired runlevel, add its number to the kernel parameters (e.g. for runlevel 3).

The run-level was appended to the end so the kernel knows what run-level to start with. To use another init program (e.g. systemd), add or similar.

Note: If using some init other than sysvinit, the runlevel parameter might be ignored.

After boot up

After the system has booted up, you may issue to inform init to change the runlevel to . init then reads inittab and «diffs» runlevel n and current runlevel — killing processes not present in the new runlevel and carrying out actions not present in the old runlevel. Processes present in both runlevels are left untouched. The killing procedure is actually a little complex; again, technical details can be found in the init manpage.

init does not watch inittab. You need to call explicitly to apply modifications to inittab. The command causes init to re-examine inittab but not switch runlevel.

5. Upstart

Upstart — это система инициализации на основе событий, разработанная в Canonical и призванная заменять SysV. Она может запускать системные службы, выполнять над ними различные задачи, инспектировать их во время выполнения, а также выполнять нужные действия в ответ на события в системе.

Это гибридная система инициализации, она использует как SysV скрипты запуска, так и файлы служб Systemd. Вот ее самые заметные особенности:

• Изначально разработанная для Ubuntu, но может использоваться и в других дистрибутивах;
• Запуск и остановка служб на основе событий;
• Генерация событий во время запуска и остановки служб;
• События могут быть отправлены обычными процессами;
• Связь с процессом инициализации через DBus;
• Пользователи могут запускать и останавливать свои процессы;
• Перезапуск служб, которые неожиданно завершились;
• Параллельная загрузка сервисов;
• Автоматический перезапуск служб;

Большинство ее возможностей работают благодаря интеграции с системой инициализации Systemd. В последнее время всё меньше используются скрипты SysV init и всё больше применяются юнит файлы Systemd. Рано или поздно Systemd вытеснит и полностью заменит Upstart в Ubuntu.

Как определить какая система инициализации у меня?

Способ №1: Команда ps

С помощью мы можем отобразить информацию об активном процессе, а с помощью указать необходимые фильтры для определения текущей системы инициализации:

Debian 11 (Testing)

Fedora 34 Workstation

Как вы можете видеть, в Debian и Fedora используется система инициализации systemd.

В случае использования системы инициализации SysV, вывод команды будет следующий:

MX Linux 19.4

Если же у вас используется система инициализации Upstart, то вы увидите:

Способ №2: Команда rpm

rpm (сокр. от «Red Hat Package Manager») — это мощная консольная утилита управления пакетами в дистрибутивах RHEL, CentOS, Fedora, openSUSE и Mageia. Команда позволяет устанавливать, обновлять, удалять, запрашивать и проверять программное обеспечение.

Чтобы узнать, какая система инициализации установлена, нужно выполнить следующую команду:

Примечание: /usr/sbin/init или /sbin/init — это исполняемый файл, запускающий систему инициализации SysV. По соображениям совместимости при установке systemd файл /sbin/init является псевдонимом (или символьной ссылкой) исполняемого файла системы инициализации systemd.

Fedora 34 Workstation

В случае использования системы инициализации SysV, вывод будет следующий:

В случае использования системы инициализации Upstart, вывод будет следующий:

Важное примечание

Может случиться так, что, используя ОС с systemd в качестве системы инициализации и набрав в терминале команды и , мы увидим следующий результат:

Debian 11 (Testing)

То есть назначен процессу init, а процесс systemd имеет . Получается, что у нас используется SysV? Но мы ведь уверены в том, что устанавливали дистрибутив (Debian) с системой инициализации systemd! Это можно проверить с помощью следующей команды:

Debian 11 (Testing)

Так почему же возникла путаница с ? Если мы проверим тип файла /sbin/init (который является файлом, запускающим систему инициализации SysV), то увидим, что в нашем случае /sbin/init является символьной ссылкой на /lib/systemd/systemd (главный файл системы инициализации systemd):

Debian 11 (Testing)

Таким образом, в нашей ОС используется именно systemd.

Writing rc.d scripts

Initscripts uses rc.d scripts to used to control the starting, stopping and restarting of daemons.

Guideline

• Source , , and optionally .
• Arguments and other daemon options should be placed in . This is done to separate configuration from logic and to keep a consistent style among daemon scripts.
• Use functions in instead of duplicating their functionality.
• Include at least start, stop and restart as arguments to the script.

Available functions

• There are some functions provided by :
  • : set status busy for printed message (e.g. Starting daemon )
  • : set status done (e.g. Starting daemon )
  • : set status failed (e.g. Starting daemon )
  • : get PID of the program
  • : check whether PID-file is still valid for the program (e.g. ck_pidfile /var/run/daemon.pid daemon || rm -f /var/run/daemon.pid)
  • : add/remove program to running daemons (stored in )

Full list of functions is much longer and most possibilities (like way to control whether or not non-root users can launch daemon) are still undocumented and can be learned only from source. See also .

Example

The following is an example for crond. Look in for greater variety.

The configuration file:

/etc/conf.d/crond

ARGS="-S -l info"

The actual script:

/etc/rc.d/crond

#!/bin/bash

. /etc/rc.conf
. /etc/rc.d/functions

DAEMON=crond
ARGS=

[ -r /etc/conf.d/$DAEMON ] && . /etc/conf.d/$DAEMON

PID=$(get_pid $DAEMON)

case "$1" in
 start)
   stat_busy "Starting $DAEMON"
    && $DAEMON $ARGS &>/dev/null
   if ; then
     add_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 stop)
   stat_busy "Stopping $DAEMON"
    && kill $PID &>/dev/null
   if ; then
     rm_daemon $DAEMON
     stat_done
   else
     stat_fail
     exit 1
   fi
   ;;
 restart)
   $0 stop
   sleep 1
   $0 start
   ;;
 *)
   echo "usage: $0 {start|stop|restart}"  
esac

Система инициализации в Unix/Linux

Существует несколько способов проверить это, сейчас я покажу как это сделать.

-=== СПОСОБ 1 — проверка  PID процессов==-

Например, Ubuntu до версии 14 использовала систему инициализацию Upstart чтобы проверить это, выполните:

$ ps aux | grep upstart

Или:

$ ps -p 1

Например, Ubuntu 16 и CentOS 7 использовала систему инициализацию SystemD чтобы проверить это, выполните:

$ ps aux | grep systemd

Или если используется Ubuntu 16, можно выполнить:

$ ps -p 1

Еще вариант:

$ ps -s1

Или, другой пример:

$ ps -1

А так же:

$ (ps -eo "ppid,args" 2>/dev/null || echo "ps call error") | awk 'NR==1 || $1==1'

Или (если чтобы было красиво):

$ ps -s1 | awk '{print $4}'| grep -Ev "CMD"

Например, CentOS 6 использовала систему инициализацию Upstart, но с init процессом и чтобы проверить это, выполните:

$ ps aux | grep init

-=== СПОСОБ 2 — проверка файлов==-

Запускаем следующую команду:

$ /sbin/init --version

Если на сервере используется init  инициализация, то она отобразится при выводе. В противном случае — скажет что такой команды нет.

Или:

# initctl --version

ИЛИ, можно выполнить:

$ file /sbin/init

Вот вам еще довольно стоящий пример:

# strings /sbin/init | grep -q "/lib/systemd" && echo SYSTEMD
# strings /sbin/init | grep -q "upstart" && echo UPSTART
# strings /sbin/init | grep -q "sysvinit" && echo SYSVINIT

Соединил воедино:

$ strings /sbin/init | awk 'match($0, /(upstart|systemd|sysvinit)/) { print toupper(substr($0, RSTART, RLENGTH));exit; }'

Не плохо, да?)

-=== СПОСОБ 3 — с помощью ФС==-

Можно запустить следующую команду:

# ls -l /proc/1/exe

Команда что выше, проверяет  exe симлинку в папке /proc/1.  А собственно «1» – это PID 1-го процесса.

Или:

$ { ls -l /proc/1/fd |grep -q systemd && echo "init: systemd"; } || \
{ ls -l /proc/1/fd |grep -q /run/initctl && echo "init: sysvinit"; } || \
{ ls -l /proc/1/fd |grep -q upstart && echo "init: upstart"; } || \
{ ls -l /proc/1/exe |grep -q busybox && echo "init: busybox"; } || \
echo "unknown init"

-=== СПОСОБ 4 — с помощью готового bash скрипта==-

Создаем скрипт:

# vim INIT.sh

И прописываем в него:

#!/usr/bin/env bash

# init process is pid 1
INIT=`ls -l /proc/1/exe`
if ]; then
  SYSTEMINITDAEMON=upstart
elif ]; then
  SYSTEMINITDAEMON=systemd
elif [[ $INIT == *"/sbin/init"* ]]; then
  INIT=`/sbin/init --version`
  if ]; then
    SYSTEMINITDAEMON=upstart
  elif ]; then
    SYSTEMINITDAEMON=systemd
  fi
fi

if ; then
  echo "WARNING: Unknown distribution, assuming defaults - this may fail." >&2
else
  echo "Init system discovered: $SYSTEMINITDAEMON"
fi

Можно добавить прав на исполнение:

# chmod +x INIT.sh

И для запуска, юзаем:

# bash INIT.sh

-=== СПОСОБ 5 — с помощью пакетного менеджера==-

Если используете centOS/RedHat/Fedora/Suse, то можно выполнить:

$ rpm -qf /sbin/init

Если используете Debian/Ubuntu/Mint/др, то можно выполнить:

$ dpkg -S /sbin/init

-=== СПОСОБ 6 — с помощью lsof==-

Так же, можно выполнить:

$ ps -eaf| grep -E "ystemd|init|pstart"

-=== СПОСОБ 7 — с помощью ls и which==-

# ls -l `which init`

Overview of init and inittab

init is always process 1 and, other than managing some swap space, is the parent process to all other processes. You can get an idea of where init lies in the process hierarchy of your system with :

$ pstree -Ap

init(1)-+-acpid(3432)
        |-crond(3423)
        |-dbus-daemon(3469)
        |-gpm(3485)
        |-mylogin(3536)
        |-ngetty(3535)---login(3954)---zsh(4043)---pstree(4326)
        |-polkitd(4033)---{polkitd}(4035)
        |-syslog-ng(3413)---syslog-ng(3414)
        `-udevd(643)-+-udevd(3194)
                     `-udevd(3218)

Besides usual initialization of system (as the name suggests), init also handles rebooting, shutdown and booting into recovery mode (single-user mode). To support these, inittab groups entries into different runlevels. The runlevels Arch uses are 0 for halt, 1 (aliased as S) for single-user mode, 3 for normal booting (multi-user mode), 5 for X and 6 for reboot. Other distros may adopt other conventions, but the meanings of 0, 1 and 6 are universal.

Upon execution, init scans inittab and carry out appropriate actions. An entry in inittab takes the form

id:runlevels:action:process

Where is a unique identifier for the entry (just a name, no real impact on init), and is a (not delimited) string of runlevels. If the runlevel init is entering appears in , is carried out, executing if appropriate. Some special s would cause init to ignore and adopt a special matching method. More explanation follows in the next section.

See also and .