Sysv linux ��� ���

SysVinit

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

This article or section is out of date.

On systems based on SysVinit, init is the first process that is executed once the Linux kernel loads. The default init program used by the kernel is /sbin/init provided by systemd-sysvcompat (by default on new installs, see systemd) or sysvinit AUR . The word init will always refer to sysvinit in this article.

inittab is the startup configuration file for init located in /etc . It contains directions for init on what programs and scripts to run when entering a specific runlevel.

Although a SysVinit-based Arch system does use init, most of the work is delegated to the #Main Boot Scripts. This article concentrates on init and inittab.

Contents

Installation

Install sysvinit AUR initscripts-fork AUR from the AUR. This step will remove systemd-sysvcompat , and you will use sysvinit on reboot. To restore systemd, append init=/usr/lib/systemd/systemd to the kernel command line.

A snapshot of init scripts as packaged in Arch Linux before migration to systemd is available at arch-rcscripts. For support with newer packages, see #Writing rc.d scripts.

See Init#Configuration for generic configuration steps.

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 :

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

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

See also man 5 inittab and man 8 init .

Switching runlevel

Through bootloader

To change the runlevel the system boots into, simply add the desired runlevel n to the respective bootloader’s configuration line. A common application of this is Xinit#Autostart X at login. To boot to the desired runlevel, add its number to the kernel parameters (e.g. 3 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 init=/usr/lib/systemd/systemd or similar.

After boot up

After the system has booted up, you may issue telinit n to inform init to change the runlevel to n . 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 telinit explicitly to apply modifications to inittab. The command telinit q causes init to re-examine inittab but not switch runlevel.

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.

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:

Main Boot Scripts

These are the main Arch init scripts.

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 /sbin/sulogin instead of /sbin/login to control the login process. You can also boot into single-user mode by appending the letter S 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.

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.

Ctrl+Alt+Del

When the special key sequence Ctrl+Alt+Del is pressed, this determines what to do.

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.

Power-Sensing Scripts

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

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 Ctrl+Alt+Del .

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:

Causes wall to write to all ttys:

Writing rc.d scripts

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

Guideline

• Source /etc/rc.conf , /etc/rc.d/functions , and optionally /etc/conf.d/DAEMON_NAME .
• Arguments and other daemon options should be placed in /etc/conf.d/DAEMON_NAME . This is done to separate configuration from logic and to keep a consistent style among daemon scripts.
• Use functions in /etc/rc.d/functions 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 /etc/rc.d/functions :
  • stat_busy «message» : set status busy for printed message (e.g. Starting daemon [BUSY])
  • stat_done : set status done (e.g. Starting daemon [DONE])
  • stat_fail : set status failed (e.g. Starting daemon [FAILED])
  • get_pid program : get PID of the program
  • ck_pidfile PID-fileprogram : 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|rm]_daemon program : add/remove program to running daemons (stored in /run/daemons/ )

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 /etc/rc.d/functions source. See also man rc.d .

Example

The following is an example for crond. Look in /etc/rc.d for greater variety.

The configuration file:

The actual script:

Runlevels

This article or section needs language, wiki syntax or style improvements. See Help:Style for reference.

From the init man page:

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

If something goes wrong with your Arch setup in such way that you are completely helpless when the system boots up, you may need this.

For example, if you use some deffective display drivers, the system may freeze when the X server starts. If you have a display manager in your startup daemons list, you need to take full control of your system before that daemon starts.

And how do you do that?

What you need is called «booting to another runlevel». This basically determines in what state the system will be when the boot sequence terminates. Normally you finish in the multi-user mode with all daemons started (=runlevel 3).

Comparison to systemd targets

systemd Target	SysV Runlevel	Notes
runlevel0.target, poweroff.target	0	Shut down the system.
runlevel1.target, rescue.target	1, s, single	Single user mode.
runlevel2.target, runlevel4.target, multi-user.target	2, 4	User-defined/Site-specific runlevels. By default, identical to 3.
runlevel3.target, multi-user.target	3	Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
runlevel5.target, graphical.target	5	Multi-user, graphical. Usually has all the services of runlevel 3 plus a graphical login.
runlevel6.target, reboot.target	6	Reboot
emergency.target	emergency	Emergency shell

List of initscripts runlevels

And what are the possible runlevels?

• 1: Single user (maintainance mode): You want to use this one if you have problems.
• 3: Multi user: Normal mode
• 5: Multi user with X11: The same as 3 but with X11 loaded in virtual terminal 8 by default
• 0: Halt
• 6: Reboot
• 2, 4: Not used

Take a look to /etc/inittab to see how it works.

Runlevel invocation

You specify what runlevel you would like to enter on the kernel commandline. You just have to pass the number of the desired runlevel as an option on that commandline, so it may look like this if you are in trouble and you want to use single user mode (only the last number is important here)

And yes, in a case when you can not boot, you will have to append the runlevel number to the the kernel command line in the boot manager during bootup.

Adding runlevels

First method

Throughout this page, 4 will be used for an example since it is not used by default in Arch. To create another runlevel:

The execution of sed will change /etc/rc.multi4 to look at the new DAEMONS array that will be defined in a couple of steps.

Next, we will add our new /etc/rc.multi4 script to /etc/inittab by changing this line:

You can also add a new line to /etc/inittab to execute another script or program to do anything you would like.

Example: Log into X as a single user for a special purpose:

The next step will be to add a new DAEMONS array to your /etc/rc.conf file, call it DAEMONS4=(. ) and populate this array with any daemons you would like to run for the new runlevel.

The /etc/rc.conf gives the suggestion to put a ! in front of daemons you want to disable. How this is handled in the default /etc/rc.multi , is that anything prefaced with the ! is skipped. A downside to this is if you use the above method to define a different set of daemons for your new runlevel (i.e, want to stop some, keep others going, and/or start new ones) any daemon prefaced with ! will not be stopped when switching to or from your new runlevel. The following /etc/rc.multi changes this behavior.

Here is what this does:

In runlevel 3, jack and gpm are disabled, and in runlevel 4 sshd is not needed, but jack and gpm are. The above /etc/rc.multi script will scan the daemons array and check for:

In the above example, when going from runlevel 3 to runlevel 4, syslog-ng, network, netfs, and alsa are checked and found to be running so they will be skipped. sshd will be disabled then jack and gpm will be started. And when going from runlevel 4 to runlevel 3, syslog-ng, network, netfs, and alsa are still running, so will be skipped again, but jack and gpm will be stopped, while sshd will be started again.

If you do use the above /etc/rc.multi , proper operation is for it to be both your main /etc/rc.multi and your new /etc/rc.multi4 to ensure that all daemons are processed as you desire. It will not break your system to have two different versions of /etc/rc.multi .

While your new runlevel setup should not be written over by any system updates, it is always handy to have backups on hand in the event that something unforeseen happens.

Another way, without adding any symlink

With a simple modification on /etc/rc.multi , runlevels can be simply added by adding a new DAEMONS line in /etc/rc.conf .

Here is the patch:

Now, to add a runlevel, add a new array in /etc/rc.conf (in this example I named it FOO ):

and to run the system with this runlevel, simply add runlevel=FOO to your boot arguments in LILO or GRUB.

Other distributions

Runlevels exist in all Linux distributions and while runlevel 1 is usually single-user «emergency mode», 0 means halt and 6 mean reboot, the meaning of other runlevels varies from one distribution to another.

Источник

Администрирование систем Linux. Инициализация системы и уровни исполнения

Глава 15. Инициализация системы и уровни исполнения

Во многих дистрибутивах Unix и Linux используются сценарии инициализации , которые предназначены для запуска системных демонов таким же образом, как это делалось в системе Unix System V . В данной главе приведены подробные пояснения относительно принципа работы этих сценариев.

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

Для увеличения скорости загрузки Linux силами компании Canonical была разработана система инициализации upstart , которая была впервые использована в дистрибутиве Ubuntu. В операционной системе Solaris система инициализации init также использовалась вплоть до версии Solaris 9, а для версии Solaris 10 силами компании Sun была разработана система инициализации Service Management Facility . Обе системы инициализации осуществляют запуск демонов в параллельном режиме и могут заменять сценарии инициализации SysV. Также ведется работа по реализации системы инициализации initng (init next generation).

В 2014 году ведущую роль начинает играть система инициализации systemd , которая после дистрибутива Fedora была внедрена в дистрибутивах RHEL7 и CentOS7, а также была выбрана как наиболее предпочтительная замена для системы инициализации init в дистрибутиве Debian. По этой причине в конце данной главы приведено краткое описание системы инициализации systemd .

15.1. Инициализация системы

15.1.1. Процесс с идентификатором 1

Системный загрузчик передает контроль над системой ядру ОС. После непродолжительного периода времени ядро ОС запускает демон системы инициализации . Этот демон системы инициализации ( /sbin/init ) является первым демоном, запущенным в рамках системы, поэтому соответствующий процесс получает идентификатор 1 (PID 1). Демон системы инициализации никогда не завершает свою работу.

15.1.2. Параметры конфигурации в файле /etc/inittab

После того, как исполняется бинарный файл /sbin/init , в первую очередь осуществляется чтение конфигурационного файла /etc/inittab . В данном файле демон будет искать значение переменной initdefault (равное 3 в примере ниже).

15.1.3. Переменная initdefault

С помощью значения переменной initdefault указывается стандартный уровень исполнения (default runlevel). В некоторых дистрибутивах Linux в файле /etc/inittab приводится краткое описание уровней исполнения подобное приведенному ниже переведенному описанию из соответствующего файла дистрибутива Red Hat Enterprise Linux 4.

Уровень исполнения 0 соответствует отключению системы. Уровень исполнения 1 используется для устранения неполадок, так как осуществить вход в систему может исключительно пользователь root, причем для входа в систему может использоваться исключительно консоль. Уровень исполнения 3 типичен для серверов, а у ровень исполнения 5 — для настольных компьютеров (на которых вход в систему осуществляется в графическом режиме). За исключением уровней исполнения 0, 1 и 6, различные уровни исполнения могут отличаться в зависимости от дистрибутива. К примеру, в дистрибутиве Debian и производных дистрибутивах Linux на уровнях исполнения 2 и 5 имеется возможность входа в систему с использованием сетевого соединения и графического интерфейса. Исходя из этого, следует всегда сверяться с корректным описанием уровней исполнения вашей системы.

15.1.4. Сценарий sysinit

Следующая строка файла конфигурации /etc/inittab в дистрибутиве Red Hat и производных дистрибутивах выглядит следующим образом:

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

Приведенная выше команда egrep может быть заменена на аналогичную приведенную ниже команду grep :

В дистрибутиве Debian после строки с переменной initdefault используется следующая строка:

Сценарий /etc/init.d/rcS в дистрибутиве Debian будет выполняться всегда (независимо от выбранного уровня исполнения). Данный сценарий на самом деле осуществляет исполнение всех сценариев из директории /etc/rcS.d/ с сортировкой имен этих сценариев в алфавитном порядке.

15.1.5. Сценарии инициализации

Демон инициализации продолжит чтение конфигурационного файла /etc/inittab и перейдет к приведенной ниже секции в случае использования дистрибутива Debian Linux.

В дистрибутиве Red Hat Enterprise Linux соответствующая секция является идентичной за исключением использования директории init.d вместо rc.d .

В обоих случаях демон инициализации должен осуществить запуск сценария инициализации с единственным параметром, который соответствует уровню исполнения. На самом деле поля в конфигурационном файле /etc/inittab разделены с помощью символов двоеточия. Второе поле описывает уровень исполнения на котором команда из данной строки должна быть выполнена. Таким образом, в обоих случаях происходит выполнение только одной из семи команд в зависимости от текущего уровня исполнения, установленного с помощью переменной initdefault .

15.1.6. Директории для хранения сценариев инициализации

Если вы рассмотрите содержимое одной из директорий /etc/rcX.d/ , вы можете обнаружить множество сценариев (или ссылок на сценарии), имена которых начинаются либо с буквы K, либо с буквы S в верхнем регистре.

Директории /etc/rcX.d/ содержат только ссылки на сценарии, расположенные в директории /etc/init.d/ . Благодаря ссылкам появляется возможность использования сценариев с отличными именами. При переходе на новый уровень исполнения все сценарии, имена которых начинаются с буквы K или буквы S в верхнем регистре начинают исполняться после сортировки по именам в алфавитном порядке. Сценарии, имена которых начинаются с буквы K, будут исполняться в первую очередь с передачей единственного параметра stop . Остальные сценарии, имена которых начинаются с буквы S, будут исполняться с передачей единственного параметра start .

Все эти операции выполняются силами сценария /etc/rc.d/rc в дистрибутиве Red Hat и сценария /etc/init.d/rc в дистрибутиве Debian.

15.1.7. Демоны mingetty

Описание демонов mingetty в конфигурационном файле /etc/inittab

Практически в конце конфигурационного файла /etc/inittab находится секция с описанием условий запуска и перезапуска нескольких демонов mingetty .

Демоны mingetty и исполняемый файл /bin/login

Демон /sbin/mingetty выводит сообщение в виртуальной консоли и позволяет вам ввести идентификатор пользователя. После этого он выполняет бинарный файл /bin/login с передачей введенного идентификатора пользователя. Программа /bin/login проверяет, присутствует ли информация о пользователе в файле /etc/passwd и запрашивает пароль (а также проверяет его корректность). В том случае, если пароль корректен, программа /bin/login передает управление командной оболочке, установленной в файле /etc/passwd .

Перезапуск демонов mingetty

Демон инициализации осуществляет запуск демонов mingetty и отслеживает их состояние вплоть до завершения их работы (это происходит тогда, когда пользователь прекращает работу с командной оболочкой и осуществляет выход из системы). Когда это случается, демон инициализации осуществляет повторный запуск новой копии демона mingetty. Исходя из этого, даже в том случае, если вы принудительно завершите работу демона mingetty, он будет автоматически перезапущен.

В приведенном ниже примере показано, как демон инициализации перезапускает демоны mingetty. Обратите внимание на идентификаторы двух последних процессов mingetty.

При использовании утилиты kill для завершения работы двух последних демонов mingetty демон инициализации будет обрабатывать сигналы завершения работы дочерних процессов и снова запускать их (с отличными идентификаторами процессов).

Деактивация демонов mingetty

Вы можете деактивировать демоны mingetty для определенного терминала, удалив номер уровня исполнения из второго поля соответствующей строки файла /etc/inittab. Не забудьте о необходимости сообщить демону инициализации об изменении его конфигурационного файла с помощью команды kill -1 1 .

В примере ниже показана методика деактивации демонов mingetty для терминалов tty3 и tty6 на уровнях исполнения 4 и 5.

15.2. Daemon или demon?

Демон (daemon) является процессом, который выполняется в фоновом режиме без связи с графическим интерфейсом или терминалом. Обычно демоны запускаются при загрузке системы и находятся в рабочем состоянии вплоть до момента завершения работы системы. В современной технической документации демоны чаще всего называются службами (services).

При разговоре о демонах Unix не следует путать слова daemons и demons. Evi Nemeth, соавтор книги «Unix System Administration Handbook» говорил о демонах следующее:

Многие уравнивают слово «daemon» со словом «demon», намекая на некоторую адскую связь между системами Unix и преисподней. Это утверждение свидетельствует о вопиющем непонимании. На самом деле, слово «daemon» является более старой формой слова «demon»; слово daemon не имеет определенного отношения к добру или злу, а вместо этого служит для описания характера или личностных качеств человека. Древнегреческая концепция «личного демона» была схожа с современной концепцией «ангела-хранителя».

15.3. Запуск и остановка демонов

Сценарии, имена которых начинаются с букв K и S, являются ссылками на реальные сценарии из директории /etc/init.d/ . Эти сценарии могут также использоваться в процессе функционирования системы для для запуска и остановки демонов (или служб). Большинство из них принимает следующие параметры: start, stop, restart, status.

К примеру, в данном случае мы осуществляем перезапуск демона samba.

Вы можете добиться аналогичного результата в дистрибутиве RHEL/Fedora, использовав утилиту service .

Также вы можете обратить внимание на утилиты chkconfig и update-rc.d .

15.4. Утилита chkconfig

Утилита chkconfig предназначена для избавления системных администраторов от необходимости вручную редактировать ссылки и сценарии в директориях /etc/init.d и /etc/rcX.d/ .

15.4.1. Команда chkconfig —list

В данном случае мы используем утилиту chkconfig для вывода списка состояний службы на различных уровнях исполнения. Как вы видите, демон (или служба) crond активируется только на уровнях исполнения со 2 по 5.

Если вы сравните приведенный выше вывод с приведенным ниже результатом поиска ссылок на сценарии, вы можете обнаружить, что отключенное состояние (off) соответствует ссылке на сценарий с именем, начинающимся на K, а включенное состояние (on) — ссылкой на сценарий с именем, начинающимся на букву S.

15.4.2. Установка уровней исполнения для службы

Обратившись к приведенному ниже примеру, вы можете узнать о том, как использовать утилиту chkconfig для деактивации (или активации) службы на определенном уровне исполнения.

В этом примере показано, как деактивировать службу crond на уровне исполнения 3.

А в этом примере показано, как активировать эту же службу crond на уровнях исполнения 3 и 4.

15.4.3. Конфигурационные данные, используемые утилитой chkconfig

Каждый сценарий в директории /etc/init.d/ может содержать дополнительные строки (и комментарий), сообщающие утилите chkconfig от том, что следует сделать со службой в той или иной ситуации. Строка, начинающаяся с # chkconfig: содержит список уровней исполнения, на которых служба должна запускаться (2345), за которым следуют значения приоритетов запуска (90) и остановки (60) службы.

15.4.4. Активация и деактивация служб

Службы могут быть активированы и деактивированы на всех уровнях исполнения с помощью единственной команды. Уровни исполнения 0, 1 и 6 всегда связаны с остановкой служб (или вызовом сценариев с передачей параметра stop ) даже в том случае, если имя сценария начинается с буквы S в верхнем регистре.

15.5. Утилита update-rc.d

15.5.1. Об утилите update-rc.d

В дистрибутиве Debian эквивалентом утилиты chkconfig является утилита с именем update-rc.d . Эта утилита предназначена главным образом для использования в рамках сценариев, поэтому в том случае, если вы предпочитаете инструменты с графическим интерфейсом, следует обратить внимание на утилиту bum .

В том случае, если в директории /etc/rcX.d/ присутствуют ссылки на сценарии, утилита update-rc.d не будет выполнять никаких действий. Описанное поведение утилиты объясняется необходимостью предотвращения перезаписи пост-установочными сценариями, использующими утилиту update-rc.d , изменений, внесенных системным администратором.

Как вы можете увидеть в следующем примере, условия запуска демона crond никоим образом не изменились.

15.5.2. Удаление системной службы

В данном случае мы удалим упоминание о системной службе cron на всех уровнях исполнения. Помните о том, что корректный способ деактивации системной службы заключается в размещении в директориях всех уровней исполнения ссылки на сценарий с именем, начинающимся с буквы K.

15.5.3. Активация системной службы

В данном примере показана методика использования утилиты update-rc.d для активации системной службы на уровнях исполнения 2, 3, 4 и 5, а также деактивации системной службы на уровнях исполнения 0, 1 и 6.

15.5.4. Нестандартная конфигурация системной службы

А в данном примере показана методика использования разработанной вами нестандартной конфигурации демона crond.

15.6. Утилита bum

На рисунке показано окно утилиты bum , работающей в расширенном режиме.

15.7. Уровни исполнения

15.7.1. Вывод информации об уровне исполнения

Вы можете узнать текущий уровень исполнения с помощью команд runlevel и who -r .

Команда runlevel является стандартной командой Linux и выводит информацию о предыдущем и текущем уровнях исполнения. В том случае, если предыдущего уровня исполнения не было, в качестве номера будет выведена буква N.

История появления команды who -r связана с системами Unix семидесятых годов прошлого века, но команда все еще работоспособна в современных системах Linux.

15.7.2. Изменение уровня исполнения

Вы можете перейти на другой уровень исполнения с помощью команды telinit . В Linux файл /sbin/telinit обычно является ссылкой (жесткой) на бинарный файл /sbin/init .

В данном примере показана методика перехода с уровня исполнения 2 на уровень исполнения 3 без перезагрузки.

15.7.3. Утилита /sbin/shutdown

Утилита shutdown используется для корректного завершения работы системы.

Стандартными аргументами, передаваемыми утилите shutdown , являются -a , -t . -h и -r .

Аргумент -a принуждает утилиту /sbin/shutdown использовать файл конфигурации /etc/shutdown.allow . Параметр -t используется для установки количества секунд, которые должны пройти между отправкой процессам сигналов TERM и KILL . Параметр -h позволяет завершить работу системы вместо перехода к уровню исполнения 1. Параметр -r сообщает утилите /sbin/shutdown о необходимости осуществления перезагрузки после завершения работы системы.

В данном примере показана методика использования утилиты shutdown с пятисекундным интервалом между отправкой сигналов TERM и KILL.

Аргумент now является меткой времени. В качестве этого аргумента может использоваться запись +м , где вместо символа м должно указываться количество минут по истечении которых работа системы должна быть завершена (очевидно, что аргумент now является псевдонимом аргумента +0 ). Утилита также примет метку времени в формате чч:мм вместо сдвига по времени в формате +м .

15.7.4. Утилиты halt, reboot и poweroff

Бинарный файл, реализующий функции утилиты /sbin/reboot , является тем же самым бинарным файлом, который используется и для реализации функций утилит /sbin/halt и /sbin/poweroff . В зависимости от используемой команды он может вести себя по-разному.

При работе с уровнями исполнения 0 или 6 команды halt , reboot и poweroff сообщат ядру ОС о необходимости осуществления отключения , перезагрузки или завершения работы системы.

Если же уровень исполнения не является уровнем 0 или 6, при вводе команды reboot в случае использования учетной записи пользователя root на самом деле произойдет вызов утилиты shutdown с параметром -r , а при вводе команды poweroff — отключение питания в процессе отключения системы.

15.7.5. Файл журнала /var/log/wtmp

При использовании команд halt , reboot и poweroff происходит запись данных в файл журнала /var/log/wtmp . Для просмотра файла журнала /var/log/wtmp удобно использовать утилиту last .

15.7.6. Сочетание клавиш Ctrl+Alt+Del

После того, как сценарий rc завершит исполнение всех описанных сценариев для управления службами, демон инициализации init продолжит читать файл конфигурации /etc/inittab. В следующей строке описано поведение демона инициализации в том случае, если пользователь нажмет клавиши Alt+Ctrl+Del на клавиатуре.

Ниже приведена команда, используемая в дистрибутиве Debian 4.0.

Данная команда очень похожа на стандартную команду, используемую в дистрибутиве Red Hat Enterprise Linux 5.2.

Одно очевидное отличие между данным командами заключается в том, что в дистрибутиве Debian принудительно используется файл конфигурации /etc/shutdown.allow , в то время, как в дистрибутиве Red Hat любому пользователю, который может нажать сочетание клавиш Ctrl+Alt+Delete , разрешается использовать утилиту shutdown .

15.7.7. ИБП и отключение питания компьютера

Демон инициализации будет читать из файла конфигурации команды, которые должны исполняться в случае отключения питания компьютера (powerfailure), восстановления питания компьютера (powerok) и нажатия сочетания клавиш Ctrl+Alt+Del . Процесс демона инициализации init никогда не будет прекращать отслеживание сбоев по питанию компьютера, а также нажатия упомянутого сочетания трех клавиш на клавиатуре.

15.8. Менеджер инициализации systemd

Можно предположить с высокой вероятностью, что менеджер инициализации systemd заменит все стандартные функции компонентов систем инициализации init/runlevel/rc. Разработчики дистрибутивов Red Hat и Debian в 2014 году приняли решение о том, что systemd заменит стандартные системы инициализации в следующих выпусках их дистрибутивов (RHEL/CentOS7 и Debian 8).

В примере ниже показан процесс systemd с идентификатором 1 , исполняющийся в ходе работы с дистрибутивом RHEL7.

В дистрибутиве Debian 8 (еще не выпущенном в сентябре 2014 года) используются лишь некоторые компоненты системы инициализации systemd , но при этом процессом с идентификатором 1 все также является процесс init .

15.8.1. Цели systemd

Первой командой, которую нужно запомнить, является команда systemctl list-units —type=target (или ее более короткий вариант systemctl -t target ). Она позволяет вывести список различных целей менеджера инициализации, присутствующих в системе.

Цели введены в качестве замены уровней исполнения и описывают определенные точки, которые должны быть достигнуты при загрузке системы. К примеру, цель graphical.target достигается тогда, когда вы получаете возможность работы с графическим интерфейсом, а цель nfs.target требует наличия функционирующего сервера nfs.

Для перехода к цели (к примеру, к цели multi-user.target ) мы должны использовать команду systemctl isolate (вместо эквивалентной команды init 3 , предназначенной для изменения уровня исполнения).

Для изменения цели, установленной по умолчанию, мы должны снова использовать команду systemctl (вместо редактирования файла /etc/inittab ).

Данная команда удаляет файл /etc/systemd/system/default.target и заменяет его на символьную ссылку на файл цели multi-user.target .

15.8.2. Зависимости systemd

Зависимости больше не описываются с помощью последовательности сценариев, отсортированной в алфавитном порядке, а задаются с помощью ссылок на файлы служб, расположенные в директории /etc/systemd/system/ . К примеру, ниже приведен список файлов служб, которые должны быть активированы для достижения цели multi-user.target в дистрибутиве Red Hat Enterprise Linux 7.

Дистрибутив Debian 8 пока не полностью мигрировал на systemd.

Обычные сценарии инициализации из директории rc заменены на файлы служб. Используйте команду systemctl list-units -t service —all (или systemctl -at service ) для получения списка всех файлов служб в вашей системе.

А это пример вывода информации о состоянии службы sshd .

15.8.3. Службы systemd

Утилиты chkconfig и service признаны ‘устаревшими’. Они заменены на утилиту systemctl .

В данном примере показан новый способ запуска и остановки системной службы.

А это новый способ остановки и деактивации системной службы.

В данном примере показан способ повторной активации и запуска системной службы.

15.8.4. Отправка сигналов при работе с systemd

Вы можете использовать менеджер инициализации systemd для прекращения работы проблемных служб.

15.8.5. Завершение работы системы средствами systemd

Команды poweroff , halt и reboot считаются устаревшими, поэтому на данный момент при их использовании происходит вызов утилиты systemctl . В приведенной ниже таблице в левом столбце перечислены устаревшие команды, а в правом — эквивалентные команды на основе утилит из комплекта поставки systemd .

Таблица 15.1. Управление питанием системы средствами systemd

Устаревшая команда	Команда в случае использования systemd
poweroff	systemctl poweroff
reboot	systemctl reboot
halt	systemctl halt
pm-suspend	systemctl suspend
pm-hibernate	systemctl hibernate

15.8.6. Удаленное использование systemd

Утилита systemctl имеет встроенный механизм для удаленного управления, который может использоваться в том случае, если в удаленной системе функционирует сервер ssh .

В данном примере показана методика использования утилиты systemctl для проверки состояния службы на удаленном сервере, работающем под управлением дистрибутива RHEL.

15.8.7. Комплект поставки systemd включает большее количество утилит

Существуют и другие инструменты.

Например, с помощью команды systemd-analyze blame можно получить список всех служб с временем загрузки каждой из них.

15.9. Практическое задание: системы инициализации

1. Измените конфигурационный файл /etc/inittab таким образом, чтобы производился перезапуск только двух демонов mingetty . Завершите работу остальных демонов mingetty и удостоверьтесь в том, что они не были перезапущены.

2. Запустите дистрибутив Red Hat Enterprise Linux в виртуальной машине. Перейдите на уровень исполнения 5, выполните команду, позволяющую вывести информацию о текущем и предыдущем уровне исполнения, после чего перейдите на уровень исполнения 3.

3. Выясните, выполняет ли сценарий sysinit установку или изменение значения переменной окружения PATH на ваших компьютерах?

4. Выведите список всех сценариев из директории init.d, которые запускаются при достижении уровня исполнения 2.

5. Разработайте сценарий, который ведет себя аналогично сценарию для управления демоном из директории /etc/init.d/ . Он должен содержать условный переход для обработки аргументов start/stop/restart и status. Протестируйте ваш сценарий!

6. Используйте утилиту chkconfig для того, чтобы ваш сценарий запускал демон при достижении уровней исполнения 3, 4 и 5 и останавливал его при достижении любого другого уровня исполнения.

15.10. Корректная процедура выполнения практического задания: системы инициализации

1. Измените конфигурационный файл /etc/inittab таким образом, чтобы производился перезапуск только двух демонов mingetty . Завершите работу остальных демонов mingetty и удостоверьтесь в том, что они не были перезапущены.

Завершение работы демонов mingetty приведет к их перезапуску средствами демона инициализации init. Вы можете отредактировать файл /etc/inittab так, как показано ниже. Не забудьте также выполнить команду kill -1 1 .

2. Запустите дистрибутив Red Hat Enterprise Linux в виртуальной машине. Перейдите на уровень исполнения 5, выполните команду, позволяющую вывести информацию о текущем и предыдущем уровне исполнения, после чего перейдите на уровень исполнения 3.

init 5 (изменение уровня исполнения можно отследить по выводу в консоли)

init 3 (и снова вы можете отследить изменение уровня исполнения по выводу в консоли)

3. Выясните, выполняет ли сценарий sysinit установку или изменение значения переменной окружения PATH на ваших компьютерах?

В дистрибутиве Red Hat следует использовать утилиту grep для поиска обращений к переменной окружения PATH в файле сценария /etc/rc.sysinit , а в дистрибутиве Debian следует осуществить поиск обращений к данной переменной как в файле /etc/rc.local , так и в файле /etc/init/rc.local . С высокой вероятностью вы можете ответить «нет» на поставленный вопрос, хотя в дистрибутиве RHEL5 сценарий rc.sysinit и устанавливает значение переменной окружения HOSTNAME.

4. Выведите список всех сценариев из директории init.d, которые запускаются при достижении уровня исполнения 2.

5. Разработайте сценарий, который ведет себя аналогично сценарию для управления демоном из директории /etc/init.d/ . Он должен содержать условный переход для обработки аргументов start/stop/restart и status. Протестируйте ваш сценарий!

Сценарий должен выглядеть аналогично приведенному ниже сценарию.

Команда touch /var/lock/subsys/pold необходима и должна осуществлять создание файла с именем, идентичным имени сценария в том случае, если вы хотите задействовать сценарий в последовательности прекращения работы демонов (для этого также необходимо создать ссылку на сценарий с именем K01pold).

6. Используйте утилиту chkconfig для того, чтобы ваш сценарий запускал демон при достижении уровней исполнения 3, 4 и 5 и останавливал его при достижении любого другого уровня исполнения.

Приведенная выше команда будет рабоать только в том случае, если в сценарии pold присутствуют строки # chkconfig: и # description: .

Источник