Linux init d default

Системный интегратор

init.d Скрипты автозапуска при включении, выключении системы.

Скрипты запускаемых служб в Linux Ubuntu располагаются в /etc/init.d

Для того, чтобы скрипт запускался автоматически во время запуска системы, надо создать символическую ссылку на скрипт и разместить её в каталоге /etc/rc.d/rcN.d, где N уровень выполнения скрипта.

Уровень 0

остановка системы (halt) — работа системы должна быть прекращена.

Уровень 1

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

Уровень 2

многопользовательский режим — пользователи могут работать на разных терминалах.

Уровень 3

многопользовательский сетевой режим — осуществляется настройка сети и запускаются сетевые службы.

Уровень 4

практически не используется.

Уровень 5

запуск графической подсистемы X11 — вход в систему осуществляется уже в графическом режиме.

Уровень 6

перезагрузка системы — останавливаются все запущенные программы и производится перезагрузка.

Чаще всего во время загрузки системы используются уровни загрузки 3 или 5.

Имя ссылки в каталоге /etc/rc.d/rcN.d имеет особый смысл, например: если сыылки /etc/rc.d/rcN.d/@K99cpu_t и /etc/rc.d/rcN.d/@S00cpu_t указывают на один и тот же файл /etc/init.d/cpu_t, то скрипт @K99cpu_t будет выполнять в cpu_t блок кода, соответствующий останову системы, а скрипт @S00cpu_t будет выполнять в cpu_t блок кода, соответствующий старту системы, Две цифры в начале имени символической ссылки определяют порядок запуска скриптов в каталоге /etc/rc.d/rcN.d.

Cкрипт запуска должен иметь специальный формат, например такой:

Главное тут в следующем, во первых скрипт должен иметь как минимум 3 возможных ключа запуска, это: start, stop, restart, поскольку именно эти основные команды используются для запуска, останова и перезапуска. Плюс ко всему к этому в самом начале файла пишутся те самые заветные цифры отвечающие за последовательность запуска:

# chkconfig: — 98 02

Где 98 это номер в последовательности запуска, а 02 это номер последовательности останова.

То есть, проще говоря, этот скрипт запуститься 98мым в последовательности очередей, а будет остановлен 2рым.

Итак для того чтоб добавить скрипт и добавить его в автозагрузку надо произвести следующую последовательность действий:

1. Создать исполняемый скрипт по шаблону приведёному выше, заменив исполняемый_файл именем файла который надо запустить.

2. Разместить исполняемый скрипт в /etc/rc.d/init

3. Выполнить команду chkconfig —add исполняемый_скрипт

4. Выполнить команду setup или servicevonf (в зависимости от того работаете вы в графическом режиме или консоли) и выбрать службу, которая будет носить имя исполняемый_скрипт.

Выполнение скрипта при включении/отключении сети

Есть директория /etc/network/ с поддиректориями if-down.d, if-pre-up.d, if-post-down.d, if-up.d. Если разместить скрипт в одной из этих поддиректорий, то он будет выполняться соответственно при выключении, перед включением, после выключения или при включении сети.

Другой способ — указать в файле /etc/network/interfaces одну из следующих директив: up, pre-up, post-up, down, pre-down, post-down. Например, строка

после включения сети выполнит скрипт script.sh. Подробнее можно почитать в man interfaces.

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

Источник

linux-notes.org

Пишем Init скрипт

Инициализация — важнейшая процедура, лежащая в основе любой операционной системы на основе Unix/Linux для управления работой каждого скрипта и службы.

Я описывал в своих статьях процесс создания скриптов для systemD/Upstart и сейчас я хотел бы написать о написании init скриптов. Тема не новая и используется давно, но я большую часть своих тем беру именно из черновиков, которые накопились за года 3-4. У меня не хватает времени на все публикации + наполнять контент максимально (по крайней мере, сразу) и по этому, имеет что имеем. Но не смотря на это, у меня уже довольно много читателей — и это хорошо, это радует!

По сути, инициализация следует за этим процессом:

• Загрузка сервера.
• Запуск init процесса (обычно как PID 1).
• Запуск предопределенного набора задач для запуска активируется последовательно.

Инициализация отвечает за то, чтобы сервер мог загрузиться и отключиться. В некоторых Unix/Linux дистрибутивах используется стандартный процесс инициализации init/systemD/Upstart.

Пишем Upstart скрипт

И так, хотелось бы рассказать как можно запускать томкат. Но для начала, нужно узнать какой механизм инициализации используется:

Т.к речь идет о sysv init/Upstart, то и продолжим тему.

PS: Вот еще полезное чтиво:

INIT скрипт может иметь следующие состояния:

• start — Служит командой для запуска службы.
• stop — Выполняет остановку службы.
• restart — Перезапуст службы, а по факту — остановка и затем запуск сервиса.
• reload — Перезагрузка службы, т.е команда для перечитывания конфигурации без перезапуска или остановки службы.
• force-reload — Перезагрузка конфигурации (перечитать конфиг), если служба поддерживает это. В противном случае — выполнит перезапуск службы.
• status — Покажет состояние службы.

Вот скилет скрипта для использования:

Данный каркас можно юзать для любых целей.

Примеры Init скрипта

Приведу наглядный пример запуска томката.

Запуск TOMCAT с init

Создадим init скрипт для запуска:

И приводим к виду:

Даем права на запуск (на исполнение):

Открываем браузер и смотрим что вышло!

Вот еще один скрипт:

Подойдет к большинству скриптов, а для остальных — можно отредактировать немного.

И, вот еще полезный довольно вариант:

Вот и все, статья «Пишем Init скрипт» завершена.

4 thoughts on “ Пишем Init скрипт ”

Неверно указана ссылка «Система инициализации SysVinit», исправьте.

Источник

6 шагов загрузки Linux на пальцах

Нажмите кнопку включения питания на вашем системнике, и спустя несколько секунд вы увидите окно входа в систему.

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

Я предлагаю вам познакомиться со следующими уровнями типичной загрузки Linux:

1. BIOS

2. MBR

3. GRUB

#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/boot/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-194.el5PAE)
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-194.el5PAE ro root=LABEL=/
initrd /boot/initrd-2.6.18-194.el5PAE.img

4. Ядро или Kernel

5. Init

6. Уровень выполнения программ (Runlevel)

• Когда Линукс выполняет свою загрузку, вы можете наблюдать загрузку различных служб. К примеру, это могут быть сообщения типа «starting Postfix … OK» (запускается Postfix). Эти службы — и называются программами уровня выполнения, выполняемые из директории, которая соответствует нужному уровню выполнения.
• Исходя из настроек по умолчанию, система будет выполнять файлы в соответствии с нижеприведенными директориями.
  • Выполнение уровня 0 – /etc/rc.d/rc0.d/
  • Выполнение уровня 1 – /etc/rc.d/rc1.d/
  • Выполнение уровня 2 – /etc/rc.d/rc2.d/
  • Выполнение уровня 3 – /etc/rc.d/rc3.d/
  • Выполнение уровня 4 – /etc/rc.d/rc4.d/
  • Выполнение уровня 5 – /etc/rc.d/rc5.d/
  • Выполнение уровня 6 – /etc/rc.d/rc6.d/
• Но имейте ввиду, что еще в каталоге /etc могут быть символические ссылки. Например, /etc/rc0.d залинкован на /etc/rc.d/rc0.d.
• В каталогах /etc/rc.d/rc*.d/ вы можете увидеть список программ, имя которых начинается из букв S и K.
• Программы, начинающиеся на S используются для запуска. S, потому что startup.
• Программы, которые начинаются с литеры K используются — правильно — для завершения работы. K, потому что kill.
• Еще есть номера рядом с буквами S и K в именах программ. Эти номера используются для определения порядка запуска этих программ.
• К примеру, S12syslog предназначен для запуска демона syslog, его порядковый номер 12. S80sendmail — для запуска демона sendmail, имеющего порядковый номер 80. Таким образом, программа syslog будет запущена перед sendmail.

Вот и все. Возможно, некоторым из вас это не ново и особого интереса не было при чтении статью, поскольку она более ориентирована на начально-средний уровень знакомства з Линуксом.
В таком случае могу лишь сказать, что «повторение — мать учения» (с).

Дополнения, исправления, уточнения

В комментариях неоднократно было апеллировано к тексту статьи, поэтому, думаю, стоит учесть некоторые важные комментарии хабрасообщества. (спасибо artemlight, 3al, Tishka17, HhyperH, Next_Alex, Ilya_Shmelykh, Aux, soomrack, Xpeh )

• artemlight:: «Ну скажем прямо — так грузятся далеко не все дистры». С ним согласилось большинство, отмечая и bsd-style init, u-boot, и хоть initrd в статье пропущен, стоить заметить, что он нужен ядру не во всех дистрибутивах. Также отмечено, что в slackware поддержка rc.d осуществляется только в качестве совместимости, а встраиваемые системы грузятся иначе. На декстопах иногда бывает EFI, а кроме того Linux популярен в мире embedded и там ещё куча разных платформ. Линукс в телефоне вообще иначе грузится.
• soomrack, ссылая на википедию: Еще хочется сделать замечание по поводу MBR, первого сектора и пр. Все несколько усложнилось за последние годы. Сейчас уместней говорить о EFI.

Источник

Администрирование систем 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: .

Источник