Глава 6: Запуск пользовательского пространства

Пользовательское пространство запускается в следующем порядке:

1. Процесс init.
2. Основные службы низшего уровня, такие как udevd и syslogd.
3. Конфигурация сети.
4. Службы среднего и высокого уровня (cron, print и т.д.).
5. Приглашения для входа в систему, графические интерфейсы и приложения высокого уровня, такие как веб-серверы.

init (инициализация) - программа пользовательского пространства, расположенная в /sbin. Её основная цель - запускать и останавливать основные служебные процессы системы.

Во всех актуальных версиях основных дистрибутивов Linux стандартной реализацией init является systemd.

В старых системах встречаются другие реализации:

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

Однако существуют существенные ограничения:

Производительность:

• Две части последовательной загрузки не могут выполняться одновременно

Управление системой:

• Сложность поиска PID демона службы (требуется ps или механизм, специфичный для службы)
• Полустандартная система записи PID (/var/run/myservice.pid)
• Много стандартного шаблонного кода в сценариях

Конфигурация:

• Мало информации о службах и конфигурации по требованию
• Большинство служб запускается только при загрузке
• Конфигурация устанавливается в основном при загрузке
• Традиционный демон inetd (для сетевых служб по требованию) уже не используется

Современные системы инициализации (такие как systemd) решают эти проблемы путём изменения способа запуска служб, порядка их контроля и настройки зависимостей.

Определить версию инициализации можно, проверив наличие определённых файлов и каталогов:

systemd:

• Наличие каталогов /usr/lib/systemd и /etc/systemd

Upstart:

• Наличие каталога /etc/init с несколько файлами .conf
• (Исключение: Debian 7 и старше используют System V init, несмотря на /etc/init)

System V init:

• Отсутствие вышеуказанных каталогов
• Наличие файла /etc/inittab

Информацию также можно получить из страницы руководства init(1).

systemd - современная реализация init в Linux, интегрирующая функциональность Unix-служб (cron, inetd). Вдохновлена launchd от Apple.

Основные отличия от традиционной init:

• Расширенное управление службами
• Отслеживание демонов после запуска
• Группировка процессов службы
• Ориентирована на выполнение задач и целей

Система использует юниты (units) для задач, содержит инструкции запуска и зависимости. Активирует юниты по мере готовности, не придерживаясь жесткой последовательности. Реагирует на системные события (uevents).

systemd управляет не только процессами/службами, но и монтированием ФС, запросами подключения сети, таймерами.

Примечание: полный список типов см. systemd(1)

При загрузке активируется целевой юнит default.target, объединяющий юниты служб и монтирования как зависимости. Зависимости образуют граф (не дерево). Юниты могут зависеть от нескольких предыдущих.

Визуализировать граф: `systemd-analyze dot` (требует фильтрации для сложных систем).

Примечание: В большинстве систем default.target → целевой юнит высокого уровня (графический интерфейс и т.д.)

Основные каталоги:

Правило: не изменяйте системные юниты (сохраняет дистрибутив), вносите изменения в /etc/systemd/system.

Проверка пути поиска:

systemctl -p UnitPath show
pkg-config systemd --variable=systemdsystemunitdir
pkg-config systemd --variable=systemdsystemconfdir

Формат из спецификации XDG Desktop Entries (.ini подобный) с секциями в квадратных скобках и переменными.

Пример dbus-daemon.service:

[Unit]
Description=D-Bus System Message Bus
Documentation=man:dbus-daemon(1)
Requires=dbus.socket
RefuseManualStart=yes

[Service]
ExecStart=/usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
ExecReload=/usr/bin/dbus-send --print-reply --system --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

[Unit] - описание, информация о зависимостях [Service] - подготовка, запуск, перезагрузка службы

Синтаксис: `$ПЕРЕМЕННАЯ`

Пример (sshd.service):

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd-keygen
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID

• $OPTIONS, $CRYPTO_POLICY - из EnvironmentFile
• $MAINPID - PID отслеживаемого процесса

Синтаксис: `%спецификатор`

• %n - имя текущего юнита
• %H - имя хоста
• %I, %i - имя экземпляра (для юнитов с @)

Пример: getty@.service → getty@tty1, getty@tty2 (динамическое создание).

Полный список см. systemd.unit(5)

systemctl - основная команда для управления systemd юнитами.

$ systemctl status sshd.service

Вывод содержит: статус загрузки, состояние (active/inactive), основной процесс (Main PID), контрольную группу (cgroup) и сообщения журнала.

Размещайте юнит-файлы в /etc/systemd/system (не перезаписываются при обновлении дистрибутива).

# Создать файл /etc/systemd/system/test1.target
[Unit]
Description=test 1
 
# Создать файл /etc/systemd/system/test2.target с зависимостью
[Unit]
Description=test 2
Wants=test1.target
 
# Активировать
systemctl start test2.target
 
# Если есть секция [Install], включить перед активацией
systemctl enable test2.target

# 1. Деактивировать
systemctl stop <unit>
 
# 2. Отключить (если есть [Install])
systemctl disable <unit>
 
# 3. Удалить юнит-файл

Примечание: Задания (jobs) - это изменения состояния юнитов, не путать с заданиями оболочки. Требуются права суперпользователя для некоторых операций.

systemd использует cgroups (группы управления ядра Linux) для отслеживания иерархии процессов. Параметр Type в юнит-файле указывает поведение службы при запуске.

Примечание: Type=simple не известен время запуска; используйте Type=notify, Type=dbus или отложенный запуск (раздел 6.3.7) для синхронизации зависимых юнитов.

Гибкая система зависимостей требует баланса между строгостью и отказоустойчивостью. Слишком строгие правила могут заблокировать доступ при сбое некритичного сервиса. systemd предлагает несколько типов зависимостей для гибкого управления:

Просмотр зависимостей:

systemctl show -p type unit

По умолчанию юниты с Requires и Wants запускаются одновременно. Для упорядочивания используйте:

• Before - текущий юнит активируется раньше перечисленных
• After - текущий юнит активируется после перечисленных

systemd ждет активного статуса юнита перед активацией зависимостей.

systemd автоматически добавляет зависимость After к Wants-зависимостям. Эти неявные зависимости вычисляются во время загрузки и не сохраняются в файлах конфигурации.

Отключить зависимости по умолчанию:

DefaultDependencies=no

Для проверки состояния системы:

• ConditionPathExists=p - путь существует
• ConditionPathIsDirectory=p - путь является каталогом
• ConditionFileNotEmpty=p - файл существует и не пуст

При ложном условии юнит не активируется, но другие зависимости активируются независимо от условия.

Раздел [Install] позволяет указывать зависимости в обратном порядке без изменения дополнительных файлов. Используйте WantedBy или RequiredBy.

Пример:

test1.target:

[Unit]
Description=test 1
 
[Install]
WantedBy=test2.target

test2.target:

[Unit]
Description=test 2

Включение юнита:

systemctl enable test1.target
# Создаст: /etc/systemd/system/test2.target.wants/test1.target

Отключение юнита:

systemctl disable test1.target

Важно: включение юнита не активирует его. Юнит с разделом [Install] считается отключенным по умолчанию и включается после перезагрузки.

Каталоги .wants и .require в /etc/systemd/system обычно управляются разделом [Install], но можно добавлять символические ссылки вручную для временных зависимостей без редактирования системных файлов юнитов.

systemd позволяет откладывать запуск юнита до момента, когда на него поступит запрос. Процесс:

1. Создается юнит systemd для сервиса (Unit A)
2. Определяется ресурс (сокет, файл, устройство)
3. Создается юнит ресурса (Unit R): .socket, .path или .device
4. systemd мониторит ресурс и активирует Unit A при обращении

При обращении к ресурсу:

1. systemd блокирует ресурс и буферизует входные данные
2. Активирует Unit A
3. Unit A берет управление ресурсом и обрабатывает буферизованные данные

Важные замечания:

• Юнит ресурсов должен охватывать все точки доступа сервиса
• Связь между юнитами может быть неявной (по имени) или явной (параметр Socket=)
• Не все серверы поддерживают взаимодействие с юнитами ресурсов

Echo-сервис на TCP-порту 22222.

echo.socket:

[Unit]
Description=echo socket
 
[Socket]
ListenStream=22222
Accept=true

echo@.service:

[Unit]
Description=echo service
 
[Service]
ExecStart=/bin/cat
StandardInput=socket

Запуск:

systemctl start echo.socket
telnet localhost 22222

Остановка:

systemctl stop echo.socket

Символ @ в имени echo@.service означает параллельные экземпляры. При Accept=true в сокет-юните systemd принимает входящие соединения и создает отдельный экземпляр для каждого. Каждый экземпляр считывает данные как стандартный ввод.

Если сервис может самостоятельно принимать соединения, исключите @ из имени и не устанавливайте Accept=true. Сервис получит полный контроль над сокетом.

Документация: systemd.socket(5), systemd.path(5), systemd.device(5), systemd.exec(5)

Юниты ресурсов ускоряют загрузку путем параллельной активации:

systemd предоставляет интерфейс юнита ресурса (R) еще до полной активации служебного юнита (E). Это позволяет зависимым юнитам (A, B, C) стартовать параллельно, а не ждать E.

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

Пример: journald и D-Bus обычно загружаются параллельно этим способом.

systemd включает поддержку задач управления системой, помимо запуска и управления сервисами. Исполняемые файлы расположены в /lib/systemd и имеют префикс systemd-.

Примеры программ:

• systemd-udevd (интегрированный в systemd demон udevd)
• systemd-fsck (простая обертка для стандартных системных утилит)

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

Справка: Неизвестную программу в /lib/systemd можно найти в man-страницах, где описаны и утилита, и соответствующий ей тип юнита.

System V init использует уровни выполнения (runlevel) для определения состояния машины - число от 0 до 6. Проверить текущий уровень:

who -r

Выход: run-level 5 2019-01-27 16:43

Уровни выполнения различают состояния: запуск, выключение, однопользовательский режим, консоль. Например, 2–4 - текстовая консоль, 5 - графический интерфейс.

Примечание: systemd поддерживает уровни выполнения как устаревшие, предпочитая им целевые юниты.

System V init - одна из старейших систем инициализации Linux. Устанавливается редко (встречается в RHEL < 7.0, встроенных системах), но пакеты могут содержать её сценарии, совместимые с systemd.

Состоит из:

• Конфигурационный файл: /etc/inittab
• Сценарии загрузки и символические ссылки

Пример строки inittab:

id:5:initdefault:
l5:5:wait:/etc/rc.d/rc 5

Команда rc 5 запускает сценарии из /etc/rc5.d:

• S (Start) - выполнить с аргументом start
• K (Kill) - выполнить с аргументом stop
• Числа 00–99 - порядок выполнения

Пример каталога rc5.d:

S10sysklogd      S20ppp           S99gpm
S12kerneld       S25netstd_nfs    S99httpd
S15netstd_init   S30netstd_misc   S99rmnologin

Команда rc выполняет их последовательно:

S10sysklogd start
S12kerneld start
S15netstd_init start
...
S99sshd start

Сценарии оболочки запускают программы из /sbin или /usr/sbin. Для редактирования используйте less или аналогичные программы.

Содержимое rc*.d - символические ссылки на файлы в /etc/init.d:

lrwxrwxrwx . . . S10sysklogd -> ../init.d/sysklogd
lrwxrwxrwx . . . S12kerneld -> ../init.d/kerneld
lrwxrwxrwx . . . S99httpd -> ../init.d/httpd

Дистрибутивы используют эту ферму ссылок (link farm) для переиспользования одних сценариев на всех уровнях выполнения.

/etc/init.d/httpd start    # Запустить
/etc/init.d/httpd stop     # Остановить

Отключить службу без удаления:

mv S99httpd _S99httpd

Префикс _ заставит rc игнорировать ссылку.

Добавить службу: скопируйте сценарий в init.d, создайте символическую ссылку в rc*.d. Несущественные службы - номера 90+, после основных систем.

Утилита run-parts запускает все исполняемые программы в каталоге в определённом порядке.

Используется в сценариях для массового запуска программ. Большинству пользователей детали неважны.

telinit - команда управления уровнями выполнения:

Предупреждение: init завершит процессы, отсутствующие в inittab для нового уровня.

systemd отслеживает System V сценарии:

1. Активирует ''<N>.target'' (N - уровень выполнения)
2. Идентифицирует скрипты в ''/etc/rc<N>.d''
3. Связывает скрипт со служебным юнитом (''foo.service'')
4. Активирует юнит, запускает с аргументом start/stop
5. Связывает процессы со служебным юнитом

Результат: можно использовать systemctl для управления, но режим совместимости всё равно запускает сценарии последовательно.

Используйте shutdown для корректного завершения:

shutdown -h now        # Остановить сейчас
shutdown -r +10        # Перезагрузить через 10 минут

Перед завершением: shutdown создаёт /etc/nologin (запрет входа), уведомляет пользователей.

1. init просит каждый процесс завершиться
2. Через время применяет сигнал TERM
3. Если не помогает - KILL для оставшихся процессов
4. Блокирует системные файлы
5. Демонтирует все FS кроме корневой
6. Ремонтирует корневую FS в режиме read-only
7. Синхронизирует буфер (sync)
8. Указывает ядру перезагрузиться/остановиться (reboot(2))

halt/reboot: вызывают shutdown, или если система уже на уровне выключения - сигналят ядру напрямую. Флаг -f (force) - быстрое выключение без проверок.

initramfs - временное пользовательское пространство перед основной загрузкой. Решает проблему: ядру нужны драйверы в виде модулей, но модули - это файлы, а FS не смонтирована.

1. Загрузчик загружает архив с модулями ядра в оперативную память
2. Ядро распаковывает архив во временную RAM-FS
3. Утилиты в initramfs загружают необходимые драйверы
4. Монтируют реальную корневую FS
5. Запускают полноценный init

Если все драйверы встроены в ядро - можно пропустить initramfs. Удалите строку initrd в GRUB (лучше через редактор меню, чем файл конфига).

Примечание: современные ядра требуют initramfs для UUID-монтирования и других функций.

Распакуйте архив:

unmkinitramfs /boot/initramfs-*.img .

Старые системы использовали cpio архивы (см. cpio(1)).

Обычно создаётся автоматически дистрибутивом. Основные утилиты:

• mkinitramfs - простая, распространённая
• dracut - более мощная

Примечание: термин initrd (initial RAM disk) - устаревший, использовал образ диска. Сейчас initramfs (cpio-архив) стандарт. Файлы конфига ещё содержат имя initrd.

При проблемах с системой используйте live-образ дистрибутива или SystemRescueCD на съёмном носителе. Live-образ - полная Linux, загружающаяся без установки.

• Проверка файловых систем
• Сброс забытого пароля
• Исправление критичных файлов (/etc/fstab, /etc/passwd)
• Восстановление резервных копий

Быстрая загрузка в root-оболочку без служб.

Недостатки: сеть часто недоступна, нет GUI, терминал может работать некорректно. Live-образ более предпочтителен.

Требует: пароль суперпользователя для входа.