Наши партнеры

UnixForum





Библиотека сайта rus-linux.net

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

Оригинал: Init and runlevels
Автор: Paul Cobbaut
Дата публикации: 12 марта 2015 г.
Перевод: A. Панин
Дата перевода: 31 марта 2015 г.

Глава 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 в примере ниже).

[paul@rhel4 ~]$ grep ^id /etc/inittab 
id:3:initdefault:

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/rc.d/rc.sysinit

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

si::sysinit:/etc/rc.d/rc.sysinit

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

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

grep "^# \(Ini\|Sta\|Che\)".

Сценарий /etc/init.d/rcS

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

si::sysinit:/etc/init.d/rcS

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

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

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

l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

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

l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6

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

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

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

[root@RHEL52 rc3.d]# ls -l | tail -4
lrwxrwxrwx 1 root root 19 окт 11  2008 S98haldaemon -> ../init.d/haldaemon
lrwxrwxrwx 1 root root 19 окт 11  2008 S99firstboot -> ../init.d/firstboot
lrwxrwxrwx 1 root root 11 янв 21 04:16 S99local -> ../rc.local
lrwxrwxrwx 1 root root 16 янв 21 04:17 S99smartd -> ../init.d/smartd

Директории /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.

[root@RHEL4b ~]# grep getty /etc/inittab 
# Run gettys in standard runlevels (Запуск gettys на различных уровнях исполнения)
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
4:2345:respawn:/sbin/mingetty tty4
5:2345:respawn:/sbin/mingetty tty5
6:2345:respawn:/sbin/mingetty tty6

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

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

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

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

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

[root@RHEL52 ~]# ps -C mingetty
  PID TTY          TIME CMD
 2407 tty1     00:00:00 mingetty
 2408 tty2     00:00:00 mingetty
 2409 tty3     00:00:00 mingetty
 2410 tty4     00:00:00 mingetty
 2411 tty5     00:00:00 mingetty
 2412 tty6     00:00:00 mingetty

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

[root@RHEL52 ~]# kill 2411 2412
[root@RHEL52 ~]# ps -C mingetty
  PID TTY          TIME CMD
 2407 tty1     00:00:00 mingetty
 2408 tty2     00:00:00 mingetty
 2409 tty3     00:00:00 mingetty
 2410 tty4     00:00:00 mingetty
 2821 tty5     00:00:00 mingetty
 2824 tty6     00:00:00 mingetty

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

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

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

[root@RHEL52 ~]# grep getty /etc/inittab 
# Run gettys in standard runlevels (запуск gettys на различных уровнях исполнения)
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:23:respawn:/sbin/mingetty tty3
4:23:respawn:/sbin/mingetty tty4
5:23:respawn:/sbin/mingetty tty5
6:23:respawn:/sbin/mingetty tty6

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.

root@laika:~# /etc/init.d/samba restart
* Stopping Samba daemons...                              [ OK ] 
* Starting Samba daemons...                              [ OK ]

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

[root@RHEL4b ~]# service smb restart
Shutting down SMB services:                              [ OK ]
Shutting down NMB services:                              [ OK ]
Starting SMB services:                                   [ OK ]
Starting NMB services:                                   [ OK ]

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

15.4. Утилита chkconfig

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

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

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

[root@RHEL52 ~]# chkconfig --list crond
crond           0:off	1:off	2:on	3:on	4:on	5:on	6:off

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

[root@RHEL52 etc]# find ./rc?.d/ -name \*crond -exec ls -l {} \;|cut -b40-
./rc0.d/K60crond -> ../init.d/crond
./rc1.d/K60crond -> ../init.d/crond
./rc2.d/S90crond -> ../init.d/crond
./rc3.d/S90crond -> ../init.d/crond
./rc4.d/S90crond -> ../init.d/crond
./rc5.d/S90crond -> ../init.d/crond
./rc6.d/K60crond -> ../init.d/crond

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

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

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

[root@RHEL52 ~]# chkconfig --level 3 crond off
[root@RHEL52 ~]# chkconfig --list crond
crond           0:off	1:off	2:on	3:off	4:on	5:on	6:off

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

[root@RHEL52 ~]# chkconfig --level 34 crond on
[root@RHEL52 ~]# chkconfig --list crond
crond           0:off	1:off	2:on	3:on	4:on	5:on	6:off

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

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

[root@RHEL52 ~]# head -9 /etc/init.d/crond | tail -5
# chkconfig: 2345 90 60
# description: cron is a standard UNIX program that runs user-specified
#              programs at periodic scheduled times. vixie cron adds a
#              number of features to the basic UNIX cron, including better
#              security and more powerful configuration options.

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

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

[root@RHEL52 ~]# chkconfig crond off
[root@RHEL52 ~]# chkconfig --list crond
crond           0:off	1:off	2:off	3:off	4:off	5:off	6:off
[root@RHEL52 ~]# chkconfig crond on
[root@RHEL52 ~]# chkconfig --list crond 
crond           0:off	1:off	2:on	3:on	4:on	5:on	6:off

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, изменений, внесенных системным администратором.

root@barry:~# update-rc.d cron remove
update-rc.d: /etc/init.d/cron exists during rc.d purge (use -f to force)

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

root@barry:~# find /etc/rc?.d/ -name '*cron' -exec ls -l {} \;|cut -b44-
/etc/rc0.d/K11cron -> ../init.d/cron
/etc/rc1.d/K11cron -> ../init.d/cron
/etc/rc2.d/S89cron -> ../init.d/cron
/etc/rc3.d/S89cron -> ../init.d/cron
/etc/rc4.d/S89cron -> ../init.d/cron
/etc/rc5.d/S89cron -> ../init.d/cron
/etc/rc6.d/K11cron -> ../init.d/cron

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

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

root@barry:~# update-rc.d -f cron remove
 Removing any system startup links for /etc/init.d/cron ...
   /etc/rc0.d/K11cron
   /etc/rc1.d/K11cron
   /etc/rc2.d/S89cron
   /etc/rc3.d/S89cron
   /etc/rc4.d/S89cron
   /etc/rc5.d/S89cron
   /etc/rc6.d/K11cron
root@barry:~# find /etc/rc?.d/ -name '*cron' -exec ls -l {} \;|cut -b44-
root@barry:~#

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

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

root@barry:~# update-rc.d cron defaults
 Adding system startup for /etc/init.d/cron ...
   /etc/rc0.d/K20cron -> ../init.d/cron
   /etc/rc1.d/K20cron -> ../init.d/cron
   /etc/rc6.d/K20cron -> ../init.d/cron
   /etc/rc2.d/S20cron -> ../init.d/cron
   /etc/rc3.d/S20cron -> ../init.d/cron
   /etc/rc4.d/S20cron -> ../init.d/cron
   /etc/rc5.d/S20cron -> ../init.d/cron

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

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

root@barry:~# update-rc.d -n cron start 11 2 3 4 5 . stop 89 0 1 6 .
 Adding system startup for /etc/init.d/cron ...
   /etc/rc0.d/K89cron -> ../init.d/cron
   /etc/rc1.d/K89cron -> ../init.d/cron
   /etc/rc6.d/K89cron -> ../init.d/cron
   /etc/rc2.d/S11cron -> ../init.d/cron
   /etc/rc3.d/S11cron -> ../init.d/cron
   /etc/rc4.d/S11cron -> ../init.d/cron
   /etc/rc5.d/S11cron -> ../init.d/cron

15.6. Утилита bum

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

Утилита bum

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

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

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

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

[root@RHEL4b ~]# runlevel 
N 3

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

[root@RHEL4b ~]# who -r
         run-level 3  Июл 28 09:15                   last=S

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

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

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

root@barry:~# runlevel 
N 2
root@barry:~# init 3
root@barry:~# runlevel 
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.

root@barry:~# shutdown -t5 -h now

Аргумент 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.

[root@RHEL52 ~]# last | grep reboot
reboot   system boot  2.6.18-128.el5   Fri May 29 11:44   (192+05:01)
reboot   system boot  2.6.18-128.el5   Wed May 27 12:10    (06:49)
reboot   system boot  2.6.18-128.el5   Mon May 25 19:34   (1+15:59)
reboot   system boot  2.6.18-128.el5   Mon Feb  9 13:20   (106+21:13)

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

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

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

root@barry:~# grep -i ctrl /etc/inittab 
# What to do when CTRL-ALT-DEL is pressed. (Что делать при нажатии сочетания клавиш CTRL-ALT-DEL.)
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now

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

[root@RHEL52 ~]# grep -i ctrl /etc/inittab 
# Trap CTRL-ALT-DELETE (Перехват сочетания клавиш CTRL-ALT-DELETE)
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

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

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

[root@RHEL52 ~]# grep ^p /etc/inittab 
pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
# ("Питание компьютера отключено; Работа системы завершается")
pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
# ("Питание компьютера восстановлено; Процесс завершения работы системы прерван")

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

root@barry:~# grep ^p /etc/inittab 
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop

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

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

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

[root@rhel7 ~]# ps fax | grep systemd | cut -c1-76
    1 ?        Ss     0:01 /usr/lib/systemd/systemd --switched-root --system
  505 ?        Ss     0:00 /usr/lib/systemd/systemd-journald
  545 ?        Ss     0:00 /usr/lib/systemd/systemd-udevd
  670 ?        Ss     0:00 /usr/lib/systemd/systemd-logind
  677 ?        Ssl    0:00 /bin/dbus-daemon --system --address=systemd: --no
 2662 pts/1    S+     0:00          \_ grep --color=auto systemd
[root@rhel7 ~]#

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

root@debian8:~# ps fax | grep systemd
 2042 ?        S      0:00 /sbin/cgmanager --daemon -m name=systemd
10127 pts/4    S+     0:00          |                    \_ grep systemd
 2777 ?        S      0:00 /lib/systemd/systemd-logind
root@debian8:~#

15.8.1. Цели systemd

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

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

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

[root@rhel7 ~]# ps fax | wc -l
169
[root@rhel7 ~]# systemctl isolate multi-user.target
[root@rhel7 ~]# ps fax | wc -l
129
[root@rhel7 ~]#

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

[root@rhel7 ~]# systemctl enable multi-user.target --force
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default\
.target'
[root@rhel7 ~]#

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

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

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

[root@rhel7 ~]# ls /etc/systemd/system/multi-user.target.wants/
abrt-ccpp.service     hypervkvpd.service      postfix.service
abrtd.service         hypervvssd.service      remote-fs.target
abrt-oops.service     irqbalance.service      rhsmcertd.service
abrt-vmcore.service   ksm.service             rngd.service
abrt-xorg.service     ksmtuned.service        rpcbind.service
atd.service           libstoragemgmt.service  rsyslog.service
auditd.service        libvirtd.service        smartd.service
avahi-daemon.service  mdmonitor.service       sshd.service
chronyd.service       ModemManager.service    sysstat.service
crond.service         NetworkManager.service  tuned.service
cups.path nfs.target  vmtoolsd.service
[root@rhel7 ~]#

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

root@debian8:~# ls /etc/systemd/system/multi-user.target.wants/ 
anacron.service       binfmt-support.service  pppd-dns.service  ssh.service
atd.service           fancontrol.service      remote-fs.target
avahi-daemon.service  lm-sensors.service      rsyslog.service

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

[root@rhel7 ~]# systemctl -at service | head -5 | column -t | cut -c1-78
UNIT                 LOAD    ACTIVE    SUB      DESCRIPTION
abrt-ccpp.service    loaded  active    exited   Install      ABRT     coredump
abrt-oops.service    loaded  active    running  ABRT         kernel   log
abrt-vmcore.service  loaded  inactive  dead     Harvest      vmcores  for
abrt-xorg.service    loaded  active    running  ABRT         Xorg     log
[root@rhel7 ~]#

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

[root@rhel7 ~]# systemctl status sshd.service
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Wed 2014-09-10 13:42:21 CEST; 55min ago
 Main PID: 1400 (sshd)
   CGroup: /system.slice/sshd.service
           --1400 /usr/sbin/sshd -D

Sep 10 13:42:21 rhel7 systemd[1]: Started OpenSSH server daemon.
Sep 10 13:42:21 rhel7 sshd[1400]: Server listening on 0.0.0.0 port 22.
Sep 10 13:42:21 rhel7 sshd[1400]: Server listening on :: port 22.
[root@rhel7 ~]#

15.8.3. Службы systemd

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

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

[root@rhel7 ~]# systemctl start crond.service
[root@rhel7 ~]# systemctl show crond.service | grep State
LoadState=loaded
ActiveState=active
SubState=running
UnitFileState=enabled
[root@rhel7 ~]# systemctl stop crond.service
[root@rhel7 ~]# systemctl show crond.service | grep State
LoadState=loaded
ActiveState=inactive
SubState=dead
UnitFileState=enabled
[root@rhel7 ~]#

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

[root@rhel7 ~]# systemctl stop crond.service
[root@rhel7 ~]# systemctl disable crond.service
rm '/etc/systemd/system/multi-user.target.wants/crond.service'
[root@rhel7 ~]# systemctl show crond.service | grep State
LoadState=loaded
ActiveState=inactive
SubState=dead
UnitFileState=disabled
[root@rhel7 ~]#

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

[root@rhel7 ~]# systemctl enable crond.service
ln -s '/usr/lib/systemd/system/crond.service' '/etc/systemd/system/multi-user.\
target.wants/crond.service'
[root@rhel7 ~]# systemctl start crond.service
[root@rhel7 ~]# systemctl show crond.service | grep State
LoadState=loaded
ActiveState=active
SubState=running
UnitFileState=enabled
[root@rhel7 ~]#

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

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

[root@rhel7 ~]# systemctl show crond.service | grep State
LoadState=loaded
ActiveState=active
SubState=running
UnitFileState=enabled
[root@rhel7 ~]# systemctl kill -s SIGKILL crond.service
[root@rhel7 ~]# systemctl show crond.service | grep State
LoadState=loaded
ActiveState=failed
SubState=failed
UnitFileState=enabled
[root@rhel7 ~]#

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.

[root@rhel7 ~]# systemctl -H root@192.168.1.65 status sshd
root@192.168.1.65's password:
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Thu 2014-09-11 13:04:10 CEST; 16min ago
   Process: 1328 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCE\
SS)
 Main PID: 1363 (sshd)
   CGroup: /system.slice/sshd.service
[root@rhel7 ~]#

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

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

systemd-analyze                 systemd-loginctl
systemd-ask-password            systemd-machine-id-setup
systemd-cat                     systemd-notify
systemd-cgls                    systemd-nspawn
systemd-cgtop                   systemd-run
systemd-coredumpctl             systemd-stdio-bridge
systemd-delta                   systemd-sysv-convert
systemd-detect-virt             systemd-tmpfiles
systemd-inhibit                 systemd-tty-ask-password-agent

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

[root@rhel7 ~]# systemd-analyze blame | head
          1.977s firewalld.service
          1.096s tuned.service
           993ms postfix.service
           939ms iprinit.service
           925ms vboxadd-x11.service
           880ms firstboot-graphical.service
           839ms accounts-daemon.service
           829ms network.service
           822ms iprupdate.service
           795ms boot.mount
[root@rhel7 ~]#

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.

[root@RHEL5 ~]# grep tty /etc/inittab 
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2:respawn:/sbin/mingetty tty3
4:2:respawn:/sbin/mingetty tty4
5:2:respawn:/sbin/mingetty tty5
6:2:respawn:/sbin/mingetty tty6
[root@RHEL5 ~]#

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

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

runlevel

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

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

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

[root@RHEL5 etc]# grep HOSTNAME rc.sysinit

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

root@RHEL5 ~# chkconfig --list | grep '2:on'

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

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

#!/bin/bash
#
# chkconfig: 345 99 01 
# description: демонстрационный сценарий pold
#
# /etc/init.d/pold
#

case "$1" in
  start)
     echo -n "Запуск pold..."
     sleep 1;
     touch /var/lock/subsys/pold
     echo "выполнено."
     echo демон pold запущен >> /var/log/messages
     ;;
  stop)
     echo -n "Остановка pold..."
     sleep 1;
     rm -rf /var/lock/subsys/pold
     echo "выполнено."
     echo демон pold остановлен >> /var/log/messages
     ;;
  *)
     echo "Использование: /etc/init.d/pold {start|stop}"
     exit 1
     ;;
esac
exit 0

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

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

chkconfig --add pold

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


Предыдущий раздел: Оглавление Следующий раздел:
Глава 14. Системный загрузчик   Глава 16. Планирование исполнения задач