Инструменты пользователя

Инструменты сайта


init

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
init [2016/01/18 02:45]
sander [Запуск по запросу и распараллеливание ресурсов в команде systemd]
init [2016/01/18 02:45] (текущий)
sander [Ссылки по systemd]
Строка 1: Строка 1:
 +====== Команда init ======
  
 +**В дистрибутивах Linux существует три основные реализации команды init.**
 +  * **System V init**. Обычная последовательная команда init (Sys V, обычно произносится sys-five). Версия Red Hat Enterprise Linux и некоторые другие используют этот вариант.
 +  * **systemd**. Набирающий силу стандарт команды init. Во многих дистрибутивах осуществлен переход на команду systemd, а в тех, где это еще не сделано,​ такой переход планируется.
 +  * **Upstart**. Команда init для версий Ubuntu. Тем не менее к моменту написания книги в Ubuntu также запланирован переход на команду systemd.
 +
 +<WRAP center round info 80%>
 +Недостаток **Sysvem V init**: в один момент времени выполняется только одна задача запуска.
 +</​WRAP>​
 +
 +===== Команда systemd =====
 +**Что происходит,​ когда во время загрузки системы запускается команда systemd**
 +
 +  - Команда systemd загружает свою конфигурацию.
 +  - Команда systemd определяет цель загрузки,​ которая обычно называется default.target.
 +  - Команда systemd определяет все зависимости для цели загрузки по умолчанию,​ зависимости зависимостей и т. д.
 +  - Команда systemd активизирует зависимые процессы и цель загрузки.
 +  - После загрузки команда systemd может реагировать на системные события (такие как uevents) и активизировать дополнительные компоненты.
 +
 +==== Модули и типы модулей ====
 +  * Модули служб. Контролируют традиционные демоны служб в системе Unix.
 +  * Модули монтирования. Контролируют присоединение файловых систем.
 +  * Целевые модули. Контролируют другие модули,​ как правило группируя их.
 +
 +**Типы юнитов systemd:**
 +  * .service – системный сервис
 +  * .target — группа юнитов systemd
 +  * .automount – точка автомонтирования файловой системы
 +  * .device – файл устройства,​ распознанного ядром
 +  * .mount – точка монтирования файловой системы
 +  * .path – файл или директория в файловой системе
 +  * .scope – процесс,​ созданный извне
 +  * .slice – группа иерархически организованных юнитов,​ управляющая системными процессами
 +  * .snapshot – сохраненное состояние менеджера systemd
 +  * .socket – сокет межпроцессного взаимодействия
 +  * .swap – Свап-устройство или свап-файл (файл подкачки)
 +  * .timer – таймер systemd
 +
 +**Можно даже составить дерево зависимостей с помощью команды**
 +
 +<code bash>
 +[root@centic ~]# systemctl
 +UNIT                                                               ​LOAD ​  ​ACTIVE SUB       ​DESCRIPTION
 +proc-sys-fs-binfmt_misc.automount ​                                 loaded active waiting ​  ​Arbitrary Executable File Formats File System Automount Point
 +sys-devices-pci0000:​0...host1-target1:​0:​0-1:​0:​0:​0-block-sr0.device loaded active plugged ​  ​VBOX_CD-ROM
 +sys-devices-pci0000:​0...host2-target2:​0:​0-2:​0:​0:​0-block-sr1.device loaded active plugged ​  ​VBOX_CD-ROM
 +sys-devices-pci0000:​00-0000:​00:​03.0-net-enp0s3.device ​             loaded active plugged ​  ​PRO/​1000 MT Desktop Adapter
 +sys-devices-pci0000:​00-0000:​00:​05.0-sound-card0.device ​            ​loaded active plugged ​  ​82801AA AC97 Audio Controller
 +sys-devices-pci0000:​0...-target0:​0:​0-0:​0:​0:​0-block-sda-sda1.device loaded active plugged ​  ​VBOX_HARDDISK
 +sys-devices-pci0000:​0...-target0:​0:​0-0:​0:​0:​0-block-sda-sda2.device loaded active plugged ​  LVM PV Z4QzU1-NOQh-Psp5-avvx-dlTo-i3wE-LTNAvA on /dev/sda2
 +sys-devices-pci0000:​0...host0-target0:​0:​0-0:​0:​0:​0-block-sda.device loaded active plugged ​  ​VBOX_HARDDISK
 +sys-devices-platform-serial8250-tty-ttyS0.device ​                  ​loaded active plugged ​  /​sys/​devices/​platform/​serial8250/​tty/​ttyS0
 +sys-devices-platform-serial8250-tty-ttyS1.device ​                  ​loaded active plugged ​  /​sys/​devices/​platform/​serial8250/​tty/​ttyS1
 +sys-devices-platform-serial8250-tty-ttyS2.device ​                  ​loaded active plugged ​  /​sys/​devices/​platform/​serial8250/​tty/​ttyS2
 +sys-devices-platform-serial8250-tty-ttyS3.device ​                  ​loaded active plugged ​  /​sys/​devices/​platform/​serial8250/​tty/​ttyS3
 +sys-devices-virtual-block-dm\x2d0.device ​                          ​loaded active plugged ​  /​sys/​devices/​virtual/​block/​dm-0
 +sys-devices-virtual-block-dm\x2d1.device ​                          ​loaded active plugged ​  /​sys/​devices/​virtual/​block/​dm-1
 +sys-module-configfs.device ​                                        ​loaded active plugged ​  /​sys/​module/​configfs
 +sys-subsystem-net-devices-enp0s3.device ​                           loaded active plugged ​  ​PRO/​1000 MT Desktop Adapter
 +-.mount ​                                                           loaded active mounted ​  /
 +boot.mount ​                    
 +
 +..............
 +</​code>​
 +==== Зависимости команды systemd ====
 +
 +
 +=== Типы зависимостей ===
 +
 +  * **Requires.** Жесткие зависимости. При активизации модуля с зависимостью Requires команда systemd пытается активизировать модуль зависимости. Если модуль зависимости дает сбой, то команда systemd деактивизирует зависимый модуль.
 +  * **Wants.** Зависимости,​ предназначенные только для активизации. Во время активизации какого-либо модуля команда systemd активизирует его Wants-зависимости,​ но не обращает внимания,​ если они дают сбой.
 +  * **Requisite.** Модули,​ которые уже должны быть активными. Перед активизацией модуля с зависимостью Requisite команда systemd сначала проверяет состояние зависимости. Если такая зависимость еще не была активизирована,​ команда systemd дает сбой при активизации модуля с этой зависимостью.
 +  * **Conflicts.** Противоположные зависимости. При активизации модуля с зависимостью Conflict команда systemd автоматически деактивизирует такую зависимость,​ если она активна.
 +
 +<WRAP center round info 80%>
 +Зависимости могут быть также подключены «реверсивно». Например,​ чтобы добавить модуль А в качестве **Wants**-зависимости для модуля Б, не обязательно добавлять зависимость **Wants** в конфигурацию модуля Б. Вместо этого можно указать его как **WantedBy**-зависимость в конфигурации модуля А. То же самое верно и для зависимости **RequiredBy**.
 +</​WRAP>​
 +
 +
 +=== Порядок следования ===
 +
 +<WRAP center round info 80%>
 +Ни один из вариантов синтаксиса,​ который вы видели,​ не определяет явным образом порядок следования модулей. По умолчанию активизация модуля с зависимостью Requires или Wants ведет к тому, что команда systemd активизирует одновременно все такие зависимости в качестве первого модуля.
 +</​WRAP>​
 +
 +Чтобы активизировать модули в определенном порядке,​ можно использовать следующие модификаторы зависимостей.
 +
 +  * **Before.** Текущий модуль будет активизирован до указанного модуля или модулей. Например,​ если в модуле foo.target будет инструкция Before=bar.target,​ команда systemd активизирует модуль foo.target перед модулем bar.target.
 +  * **After.** Текущий модуль будет активизирован после перечисленного модуля или модулей.
 +
 +=== Условные зависимости ===
 +
 +Если условная зависимость в модуле не является истинной,​ когда команда systemd пытается активизировать данный модуль,​ то этот модуль не активизируется. Например:​
 +  * ConditionPathExists=p:​ — истинно,​ если путь (файла) p существует в системе;​
 +  * ConditionPathIsDirectory=p:​ — истинно,​ если p является каталогом;​
 +  * ConditionFileNotEmpty=p:​ — истинно,​ если p является файлом ненулевой длины.
 +
 +<WRAP center round info 80%>
 +Полный перечень зависимостей можно увидеть на странице **systemd.unit(5)** руководства.
 +</​WRAP>​
 +
 +==== Конфигурация команды systemd ====
 +
 +Имеется два основных каталога для конфигурации команды **systemd**:​
 +
 +  * каталог системных модулей (настраивается глобально,​ обычно это **/​usr/​lib/​systemd/​system**)
 +  * каталог системной конфигурации (локальные определения,​ обычно это **/​etc/​systemd/​system**)
 +
 +<WRAP center round info 80%>
 +Можно выяснить текущий путь поиска для команды systemd (включая приоритет) с помощью такой команды:​
 +**# systemctl -p UnitPath show**
 +</​WRAP>​
 +
 +=== Файлы модулей ===
 +Файл модуля /​usr/​lib/​systemd/​system/​tmp.mount
 +<code bash>
 +#  This file is part of systemd.
 +#
 +#  systemd is free software; you can redistribute it and/or modify it
 +#  under the terms of the GNU Lesser General Public License as published by
 +#  the Free Software Foundation; either version 2.1 of the License, or
 +#  (at your option) any later version.
 +
 +[Unit]
 +Description=Temporary Directory
 +Documentation=man:​hier(7)
 +Documentation=http://​www.freedesktop.org/​wiki/​Software/​systemd/​APIFileSystems
 +DefaultDependencies=no
 +Conflicts=umount.target
 +Before=local-fs.target umount.target
 +
 +[Mount]
 +What=tmpfs
 +Where=/tmp
 +Type=tmpfs
 +Options=mode=1777,​strictatime
 +
 +# Make '​systemctl enable tmp.mount'​ work:
 +[Install]
 +WantedBy=local-fs.target
 +</​code>​
 +
 +**Секция [Unit]** сообщает некоторые подробности о модуле и содержит описание и сведения о зависимости. В частности,​ этот модуль настроен так, чтобы его активизация происходила до модуля local-fs.target.\\
 +
 +**Секция [Mount]** описывает данный модуль в роли модуля монтирования,​ а также сообщает детали о точке монтирования,​ типе файловой системы и параметрах монтирования.\\
 +
 +**Переменная What=** идентифицирует устройство или идентификатор UUID устройства,​ предназначенного для монтирования.\\
 +
 +=== Подключение модулей и секция [Install] ===
 +Секция **[Install]** в файле модуля sshd.service важна, поскольку она помогает понять,​ как использовать параметры зависимостей WantedBy и RequiredBy в команде systemd.
 +
 +Файл модуля /​usr/​lib/​systemd/​system/​sshd.service
 +<code bash>
 +[Unit]
 +Description=OpenSSH server daemon
 +After=network.target sshd-keygen.service
 +Wants=sshd-keygen.service
 +
 +[Service]
 +EnvironmentFile=/​etc/​sysconfig/​sshd
 +ExecStart=/​usr/​sbin/​sshd -D $OPTIONS
 +ExecReload=/​bin/​kill -HUP $MAINPID
 +KillMode=process
 +Restart=on-failure
 +RestartSec=42s
 +
 +[Install]
 +WantedBy=multi-user.target
 +</​code>​
 +
 +Когда вы включаете модуль,​ команда systemd читает секцию [Install]; в данном случае включение модуля sshd.service приводит к тому, что команда systemd видит зависимость WantedBy для модуля multi-user.target. В ответ на это команда systemd следующим образом создает в каталоге системной конфигурации символическую ссылку на модуль sshd.service:​
 +<code bash>
 +ln -s '/​usr/​lib/​systemd/​system/​sshd.service'​ '/​etc/​systemd/​system/​multi-user.target.wants/​sshd.service'​
 +</​code>​
 +
 +=== Переменные и спецификаторы ===
 +
 +  * Значения переменной **$OPTIONS** являются параметрами,​ которые можно передать команде sshd при активизации данного модуля командой systemctl
 +  * Значение переменной **$MAINPID** — это отслеживаемый процесс службы
 +
 +**Спецификатор** — это еще одно похожее на переменную средство,​ которое часто можно увидеть в файлах модулей. Спецификаторы начинаются с символа процента (%).
 +  * спецификатор %n представляет имя текущего модуля
 +  * спецификатор %H — имя текущего хоста
 +
 +==== Работа команды systemd ====
 +
 +<WRAP center round info 80%>
 +С командой systemd вы будете взаимодействовать главным образом с помощью команды systemctl, которая позволяет активизировать и деактивизировать службы,​ выводить статус,​ перезагружать конфигурацию и многое другое.
 +</​WRAP>​
 +
 +**Увидеть список активных модулей в вашей системе**
 +<code bash>
 +systemctl list-units
 +#или просто ​
 +systemctl
 +#​полные названия модулей
 +systemctl --full
 +#все модули,​ в т.ч. не активные
 +systemctl --all
 +</​code>​
 +**Статус модуля**
 +<code bash>
 +[root@centic multi-user.target.wants]#​ systemctl status sshd
 +sshd.service - OpenSSH server daemon
 +   ​Loaded:​ loaded (/​usr/​lib/​systemd/​system/​sshd.service;​ enabled)
 +   ​Active:​ active (running) since Чт 2016-01-14 16:36:54 MSK; 20h ago
 + Main PID: 1134 (sshd)
 +   ​CGroup:​ /​system.slice/​sshd.service
 +           ​└─1134 /​usr/​sbin/​sshd -D
 +
 +янв 14 16:36:54 centic systemd[1]: Started OpenSSH server daemon.
 +янв 14 16:36:54 centic sshd[1134]: Server listening on 0.0.0.0 port 22.
 +янв 14 16:36:54 centic sshd[1134]: Server listening on :: port 22.
 +янв 14 16:44:45 centic sshd[2488]: Accepted password for root from 172.16.4.5 port 62089 ssh2
 +янв 14 16:53:28 centic sshd[2575]: Accepted password for root from 172.16.4.5 port 62598 ssh2
 +</​code>​
 +
 +**Полный журнал модуля**
 +<code bash>
 +[root@centic ~]# journalctl _SYSTEM_UNIT=sshd
 +-- Logs begin at Чт 2016-01-14 16:36:39 MSK, end at Пт 2016-01-15 13:01:01 MSK. --
 +</​code>​
 +
 +Для активизации,​ деактивизации и перезапуска модулей используйте команды **systemd start**, **stop** и **restart**. Однако если вы изменили файл конфигурации модуля,​ можно перезагрузить такой файл одним из двух способов:​
 +  * systemctl reload unit — перезагружает только конфигурацию модуля unit;
 +  * systemctl daemon-reload — перезагружает конфигурацию всех модулей.
 +
 +==== Добавление модулей в команду systemd ====
 +
 +1. Создайте файл модуля с именем test1.target:​
 +<code bash>
 +[Unit]
 +Description=test 1
 +</​code>​
 +2. Создайте файл test2.target с зависимостью от файла test1.target:​
 +<code bash>
 +[Unit]
 +Description=test 2
 +Wants=test1.target
 +</​code>​
 +3. Активизируйте модуль test2.target (помня о том, что зависимость в файле test2.target вынуждает команду systemd активизировать при этом и модуль test1.target):​
 +<code bash>
 +# systemctl start test2.target
 +</​code>​
 +4. Убедитесь в том, что оба модуля активны:​
 +<code bash>
 +# systemctl status test1.target test2.target
 +test1.target - test1
 +   ​Loaded:​ loaded (/​etc/​systemd/​system/​test1.target;​ static)
 +   ​Active:​ active since Пт 2016-01-15 13:38:24 MSK; 1min 42s ago
 +
 +янв 15 13:38:24 centic systemd[1]: Starting test1.
 +янв 15 13:38:24 centic systemd[1]: Reached target test1.
 +
 +test2.target - test2
 +   ​Loaded:​ loaded (/​etc/​systemd/​system/​test2.target;​ static)
 +   ​Active:​ active since Пт 2016-01-15 13:38:24 MSK; 1min 42s ago
 +
 +янв 15 13:38:24 centic systemd[1]: Starting test2.
 +янв 15 13:38:24 centic systemd[1]: Reached target test2.
 +</​code>​
 +
 +<WRAP center round info 80%>
 +Если в файле модуля есть секция [Install], подключите модуль до его активизации:​\\
 +# systemctl enable unit\\
 +Опробуйте это на предыдущем примере. Удалите зависимость из файла test2.target и добавьте секцию [Install] в файл test1.target,​ содержащую строку WantedBy=test2.target.
 +</​WRAP>​
 +
 +**Удаление модулей. Чтобы удалить модуль,​ выполните следующее.**\\
 +1. Если необходимо,​ деактивизируйте модуль:​
 +<code bash>
 +# systemctl stop unit
 +</​code>​
 +2. Если в модуле есть секция [Install], отключите модуль,​ чтобы удалить все зависимые символические ссылки:​
 +<code bash>
 +# systemctl disable unit
 +</​code>​
 +3. Удалите файл модуля,​ если желаете.
 +
 +==== Отслеживание процессов и синхронизация в команде systemd ====
 +
 +<WRAP center round info 80%>
 +Чтобы свести к минимуму объем работы,​ который программист или администратор должен выполнить для создания работающего модуля,​ команда systemd использует группы управления (cgroups) — необязательную функцию ядра Linux, которая предусматривает более точное отслеживание иерархии процессов.
 +</​WRAP>​
 +
 +Существуют два основных стиля запуска.
 +  * **Type=simple** — процесс службы не ветвится.
 +  * **Type=forking** — служба ветвится,​ и команда systemd ожидает завершения исходного процесса службы. По его завершении команда systemd предполагает,​ что данная служба готова.
 +
 +==== Запуск по запросу и распараллеливание ресурсов в команде systemd ====
 +<WRAP center round info 80%>
 +Одной из самых важных функций команды systemd является ее способность откладывать запуск модуля до тех пор, пока он не станет абсолютно необходим.
 +</​WRAP>​
 +==== Ссылки по systemd ====
 +
 +[[http://​habrahabr.ru/​company/​infobox/​blog/​241237/​|Шпаргалка по управлению сервисами CentOS 7 с systemd]]
 +===== Команда System V init =====
 +
 +<WRAP center round info 80%>
 +В типичный состав команды System V init входят два главных компонента:​ центральный файл конфигурации и большой набор сценариев загрузки системы,​ дополненный фермой символических ссылок.
 +</​WRAP>​
 +
 +В файле /​etc/​inittab строка id:​N:​initdefault:​ указывает номер уровня запуска по умолчанию. \\
 +
 +Все строки файла inittab построены по следующему шаблону,​ в котором четыре поля отделяются двоеточиями:​
 +  * уникальный идентификатор (короткая строка,​ как id в приведенном примере);​
 +  * применимое значение уровня запуска (или несколько значений);​
 +  * действие,​ которое следует выполнить команде init (в приведенном примере — установить по умолчанию значение 5 для уровня запуска);​
 +  * команда на выполнение (необязательна).
 +
 +**Действия:​**
 +  * **wait** определяет,​ когда и как команда System V init запускает команду:​ она должна запустить один раз команду , а затем, прежде чем делать что-либо еще, дождаться завершения ее работы.
 +  * **respawn** говорит команде init о том, чтобы она запустила следующую дальше команду и, если выполнение команды завершилось,​ запустила ее снова.
 +  * **ctrlaltdel** управляет тем, что выполняет система,​ когда вы нажимаете сочетание клавиш Ctrl+Alt+Delete в виртуальной консоли.
 +  * **sysinit** команда должна выполнить в самую первую очередь,​ перед переходом на какой-либо из уровней запуска.
init.txt · Последние изменения: 2016/01/18 02:45 — sander