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

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


init

Команда init

В дистрибутивах Linux существует три основные реализации команды init.

  • System V init. Обычная последовательная команда init (Sys V, обычно произносится sys-five). Версия Red Hat Enterprise Linux и некоторые другие используют этот вариант.
  • systemd. Набирающий силу стандарт команды init. Во многих дистрибутивах осуществлен переход на команду systemd, а в тех, где это еще не сделано, такой переход планируется.
  • Upstart. Команда init для версий Ubuntu. Тем не менее к моменту написания книги в Ubuntu также запланирован переход на команду systemd.

Недостаток Sysvem V init: в один момент времени выполняется только одна задача запуска.

Команда systemd

Что происходит, когда во время загрузки системы запускается команда systemd

  1. Команда systemd загружает свою конфигурацию.
  2. Команда systemd определяет цель загрузки, которая обычно называется default.target.
  3. Команда systemd определяет все зависимости для цели загрузки по умолчанию, зависимости зависимостей и т. д.
  4. Команда systemd активизирует зависимые процессы и цель загрузки.
  5. После загрузки команда systemd может реагировать на системные события (такие как uevents) и активизировать дополнительные компоненты.

Модули и типы модулей

  • Модули служб. Контролируют традиционные демоны служб в системе Unix.
  • Модули монтирования. Контролируют присоединение файловых систем.
  • Целевые модули. Контролируют другие модули, как правило группируя их.

Типы юнитов systemd:

  • .service – системный сервис
  • .target — группа юнитов systemd
  • .automount – точка автомонтирования файловой системы
  • .device – файл устройства, распознанного ядром
  • .mount – точка монтирования файловой системы
  • .path – файл или директория в файловой системе
  • .scope – процесс, созданный извне
  • .slice – группа иерархически организованных юнитов, управляющая системными процессами
  • .snapshot – сохраненное состояние менеджера systemd
  • .socket – сокет межпроцессного взаимодействия
  • .swap – Свап-устройство или свап-файл (файл подкачки)
  • .timer – таймер systemd

Можно даже составить дерево зависимостей с помощью команды

[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                     
 
..............

Зависимости команды systemd

Типы зависимостей

  • Requires. Жесткие зависимости. При активизации модуля с зависимостью Requires команда systemd пытается активизировать модуль зависимости. Если модуль зависимости дает сбой, то команда systemd деактивизирует зависимый модуль.
  • Wants. Зависимости, предназначенные только для активизации. Во время активизации какого-либо модуля команда systemd активизирует его Wants-зависимости, но не обращает внимания, если они дают сбой.
  • Requisite. Модули, которые уже должны быть активными. Перед активизацией модуля с зависимостью Requisite команда systemd сначала проверяет состояние зависимости. Если такая зависимость еще не была активизирована, команда systemd дает сбой при активизации модуля с этой зависимостью.
  • Conflicts. Противоположные зависимости. При активизации модуля с зависимостью Conflict команда systemd автоматически деактивизирует такую зависимость, если она активна.

Зависимости могут быть также подключены «реверсивно». Например, чтобы добавить модуль А в качестве Wants-зависимости для модуля Б, не обязательно добавлять зависимость Wants в конфигурацию модуля Б. Вместо этого можно указать его как WantedBy-зависимость в конфигурации модуля А. То же самое верно и для зависимости RequiredBy.

Порядок следования

Ни один из вариантов синтаксиса, который вы видели, не определяет явным образом порядок следования модулей. По умолчанию активизация модуля с зависимостью Requires или Wants ведет к тому, что команда systemd активизирует одновременно все такие зависимости в качестве первого модуля.

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

  • Before. Текущий модуль будет активизирован до указанного модуля или модулей. Например, если в модуле foo.target будет инструкция Before=bar.target, команда systemd активизирует модуль foo.target перед модулем bar.target.
  • After. Текущий модуль будет активизирован после перечисленного модуля или модулей.

Условные зависимости

Если условная зависимость в модуле не является истинной, когда команда systemd пытается активизировать данный модуль, то этот модуль не активизируется. Например:

  • ConditionPathExists=p: — истинно, если путь (файла) p существует в системе;
  • ConditionPathIsDirectory=p: — истинно, если p является каталогом;
  • ConditionFileNotEmpty=p: — истинно, если p является файлом ненулевой длины.

Полный перечень зависимостей можно увидеть на странице systemd.unit(5) руководства.

Конфигурация команды systemd

Имеется два основных каталога для конфигурации команды systemd:

  • каталог системных модулей (настраивается глобально, обычно это /usr/lib/systemd/system)
  • каталог системной конфигурации (локальные определения, обычно это /etc/systemd/system)

Можно выяснить текущий путь поиска для команды systemd (включая приоритет) с помощью такой команды: # systemctl -p UnitPath show

Файлы модулей

Файл модуля /usr/lib/systemd/system/tmp.mount

#  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

Секция [Unit] сообщает некоторые подробности о модуле и содержит описание и сведения о зависимости. В частности, этот модуль настроен так, чтобы его активизация происходила до модуля local-fs.target.

Секция [Mount] описывает данный модуль в роли модуля монтирования, а также сообщает детали о точке монтирования, типе файловой системы и параметрах монтирования.

Переменная What= идентифицирует устройство или идентификатор UUID устройства, предназначенного для монтирования.

Подключение модулей и секция [Install]

Секция [Install] в файле модуля sshd.service важна, поскольку она помогает понять, как использовать параметры зависимостей WantedBy и RequiredBy в команде systemd.

Файл модуля /usr/lib/systemd/system/sshd.service

[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

Когда вы включаете модуль, команда systemd читает секцию [Install]; в данном случае включение модуля sshd.service приводит к тому, что команда systemd видит зависимость WantedBy для модуля multi-user.target. В ответ на это команда systemd следующим образом создает в каталоге системной конфигурации символическую ссылку на модуль sshd.service:

ln -s '/usr/lib/systemd/system/sshd.service' '/etc/systemd/system/multi-user.target.wants/sshd.service'

Переменные и спецификаторы

  • Значения переменной $OPTIONS являются параметрами, которые можно передать команде sshd при активизации данного модуля командой systemctl
  • Значение переменной $MAINPID — это отслеживаемый процесс службы

Спецификатор — это еще одно похожее на переменную средство, которое часто можно увидеть в файлах модулей. Спецификаторы начинаются с символа процента (%).

  • спецификатор %n представляет имя текущего модуля
  • спецификатор %H — имя текущего хоста

Работа команды systemd

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

Увидеть список активных модулей в вашей системе

systemctl list-units
#или просто 
systemctl
#полные названия модулей
systemctl --full
#все модули, в т.ч. не активные
systemctl --all

Статус модуля

[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

Полный журнал модуля

[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. --

Для активизации, деактивизации и перезапуска модулей используйте команды systemd start, stop и restart. Однако если вы изменили файл конфигурации модуля, можно перезагрузить такой файл одним из двух способов:  * systemctl reload unit — перезагружает только конфигурацию модуля unit;

  • systemctl daemon-reload — перезагружает конфигурацию всех модулей.

Добавление модулей в команду systemd

1. Создайте файл модуля с именем test1.target:

[Unit]
Description=test 1

2. Создайте файл test2.target с зависимостью от файла test1.target:

[Unit]
Description=test 2
Wants=test1.target

3. Активизируйте модуль test2.target (помня о том, что зависимость в файле test2.target вынуждает команду systemd активизировать при этом и модуль test1.target):

# systemctl start test2.target

4. Убедитесь в том, что оба модуля активны:

# 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.

Если в файле модуля есть секция [Install], подключите модуль до его активизации:
# systemctl enable unit
Опробуйте это на предыдущем примере. Удалите зависимость из файла test2.target и добавьте секцию [Install] в файл test1.target, содержащую строку WantedBy=test2.target.

Удаление модулей. Чтобы удалить модуль, выполните следующее.
1. Если необходимо, деактивизируйте модуль:

# systemctl stop unit

2. Если в модуле есть секция [Install], отключите модуль, чтобы удалить все зависимые символические ссылки:

# systemctl disable unit

3. Удалите файл модуля, если желаете.

Отслеживание процессов и синхронизация в команде systemd

Чтобы свести к минимуму объем работы, который программист или администратор должен выполнить для создания работающего модуля, команда systemd использует группы управления (cgroups) — необязательную функцию ядра Linux, которая предусматривает более точное отслеживание иерархии процессов.

Существуют два основных стиля запуска.

  • Type=simple — процесс службы не ветвится.
  • Type=forking — служба ветвится, и команда systemd ожидает завершения исходного процесса службы. По его завершении команда systemd предполагает, что данная служба готова.

Запуск по запросу и распараллеливание ресурсов в команде systemd

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

Ссылки по systemd

Команда System V init

В типичный состав команды System V init входят два главных компонента: центральный файл конфигурации и большой набор сценариев загрузки системы, дополненный фермой символических ссылок.

В файле /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