LINUX.ORG.RU
ФорумTalks

Какие события должна поддерживать система инициализации? И что она должна уметь?

 , , ,


1

2

Как я понял у каждого unit должны быть прописаны:

  • Уровень выполнения. Применяется для последовательного запуска служб в случае не разрешённого конфликта зависимостей.
  • Жёсткие зависимости. Запуск демона будет отложен до их старта.
  • Зависимости требующие service restart.
  • Зависимости требующие service reload.
  • Мягкие зависимости. По возможности они будут запущены раньше.
  • Конфликты. Службы указанные в этом списке будут отключены перед стартом демона.

Отслеживаемые юниты:

  • Роль. Одну роль могут исполнять несколько служб, например роль http-сервера могут исполнять как nginx, так и apache. А роль DNS сервера как bind, так и dnsmasq.
  • Служба. Конкретный демон, например cups или winbind.
  • Файл. Доступность файла. Например если ещё не смонтирована файловая система содержащая конфигурационный файл демона или его файлы данных, то запускать его не надо, следует подождать доступности файла.
  • Точка монтирования. Проверка смонтирована ли определённая файловая система.
  • Том. Проверка наличия подключенного тома с определённым UUID или меткой
    /dev/sda3: UUID="1203d47f-2d7f-4bea-af6d-75219f8f3e3e" TYPE="swap" 
    /dev/sda1: UUID="A4F00702F006DB06" TYPE="ntfs" 
    /dev/sda7: LABEL="win_d" UUID="03C727A3587A131C" TYPE="ntfs" 
    /dev/sdb2: LABEL="bad" UUID="3CAAE04E039B8ACA" TYPE="ntfs" 
    /dev/sdb1: UUID="6f368364-ab15-47e7-8dba-2a5c32004ae4" TYPE="ext4" 
    /dev/sda2: UUID="21ec7b20-d2af-482e-9bd4-6a0e4e4ab55c" TYPE="ext4" 
    /dev/sda5: UUID="d62bff62-1c28-424f-934a-f544b60a7e08" TYPE="ext4" 
    /dev/sda6: LABEL="local" UUID="1c9e85b9-ff6f-452a-827e-cec062081d9c" TYPE="ext4"
    

  • Узел. Проверка наличия определённого узла в сети. Командой ping например.
  • Маршрут сетевой. Проверка таблицы маршрутизации на наличие определённого маршрута. Например
     192.168.0.0     *               255.255.255.0 
  • Соединение. Проверка активности определённого сетевого интерфейса.
  • USB устройство. Проверка подключения определённого usb устройства.
    Bus 003 Device 002: ID 0ac8:3450 Z-Star Microelectronics Corp. 
    Bus 004 Device 002: ID 0bda:0151 Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader)
    Bus 005 Device 002: ID 0a5c:2101 Broadcom Corp. BCM2045 Bluetooth
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 009 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    

    При этом естественно в качестве атрибута устройства можно будет указать такие параметры как его наименование Broadcom Corp. BCM2045 Bluetooth , шина к которой он подключен Bus 005, номер устройства Device 002 и ID устройства ID 0a5c:2101

Что нужно для нормальной системы инициализации?

☆☆☆

Последнее исправление: rezedent12 (всего исправлений: 1)

Роль. Одну роль могут исполнять несколько служб, например роль http-сервера могут исполнять как nginx, так и apache. А роль DNS сервера как bind, так и dnsmasq.

Роли нафиг не нужны.

Служба

Не служба, а демон, ибо не винфак

Том

Диск.

Узел, маршрут

Зачем?

USB устройство. Проверка подключения определённого usb устройства.

Зачем? Если тебе нужен BT, то легче проверить инициализацию bt-стека

У каждого init

Каждому иниту — нафиг нужно. Если ты так вбрасываешь про systemd, то шел бы ты лесом, ибо systemd — не только система инициализации. Да и большего числа перечисленного шлака там нету.

derlafff ★★★★★
()
Последнее исправление: derlafff (всего исправлений: 3)
Ответ на: комментарий от derlafff

Роли нафиг не нужны.

Почему?

Не служба, а демон, ибо не винфак

Во избежание синтаксической тавтологии. Одно и тоже.

Диск

А возможно и раздел на диске. Поэтому том.

Узел, маршрут

Зачем?

А вдруг файловая система или узел к которому надо подключиться в какой то определённой подсети.

Зачем? Если тебе нужен BT, то легче проверить инициализацию bt-стека

Это к примеру. Смысл в том что бы пользователь мог сам легко отредактировать unit файл управляющий запуском демона. Например что бы демон не запускался пока не будет вставлено определённое устройство и подключен определённый том.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от derlafff

У каждого init

Каждому иниту — нафиг нужно. Если ты так вбрасываешь про systemd, то шел бы ты лесом, ибо systemd — не только система инициализации. Да и большего числа перечисленного шлака там нету.

Unit вообще то, а не init.

rezedent12 ☆☆☆
() автор топика

Так вот ты какой, Лёня Поттеринг, был в молодости

goingUp ★★★★★
()

Какие события должна поддерживать система инициализации? И что она должна уметь?

Нам стоит готовиться к новому systemd от rezedent12?

alozovskoy ★★★★★
()

Ты ещё забыл температуру за бортом, а то, если слишком холодно, черти daemon'ы замёрзнуть могут.

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)

USB устройство. Проверка подключения определённого usb устройства.

Для этого нужно разграбить udev

goingUp ★★★★★
()
Ответ на: комментарий от alozovskoy

Нам стоит готовиться к новому systemd от rezedent12?

К systemDown :) Расслабитесь, я провожу прощупывание на предмет востребованности функционала.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от goingUp

Для этого нужно разграбить udev

Всего то следить за системным журналом или проверять вывод blkid.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

Это к примеру. Смысл в том что бы пользователь мог сам легко отредактировать unit файл управляющий запуском демона. Например что бы демон не запускался пока не будет вставлено определённое устройство и подключен определённый том.

Переизобретать udev? Разве что интеграцию с ним сделать, да и то не нужно в каждом ините, ибо с udev можно работать и без интеграции.

А возможно и раздел на диске. Поэтому том.

Диск — это диск, а раздел — это раздел. Том — НЕХ, путаница и поэтому нафиг нужно.

Почему не нужны роли?

Потому что «ролями» (фу, опять вендотермин. Тебя там вендузятник покусал?) у тебя и так рулит пакетный менеджер. Зачем переизобретать это еще и на уровне инита?

А вдруг файловая система или узел к которому надо подключиться в какой то определённой подсети.

Файловая система может вылететь и по множеству других причин, легче запускать её после запуска соединения и всё.

derlafff ★★★★★
()
Ответ на: комментарий от derlafff

Потому что «ролями» (фу, опять вендотермин. Тебя там вендузятник покусал?) у тебя и так рулит пакетный менеджер. Зачем переизобретать это еще и на уровне инита?

Ладно. Значит нинужно.

Диск — это диск, а раздел — это раздел. Том — НЕХ, путаница и поэтому нафиг нужно.

Окай. Хотя не совсем понятно.

Переизобретать udev? Разве что интеграцию с ним сделать, да и то не нужно в каждом ините, ибо с udev можно работать и без интеграции.

Какая ещё интеграция? Просто журнал просматривать и всё.

Файловая система может вылететь и по множеству других причин, легче запускать её после запуска соединения и всё.

В случае параллельного запуска демонов, поднятия сетевых соединений и монтирования файловых систем потенциально может возникнуть «гонка» и тут нужна система семафоров.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от rezedent12

Какая ещё интеграция? Просто журнал просматривать и всё.

Там же теперь можно на udev-события юниты вешать, не?

derlafff ★★★★★
()
Ответ на: комментарий от derlafff

Там же теперь можно на udev-события юниты вешать, не?

Но к udev это не будет прибито гвоздями. Можно будет использовать что угодно другое пишущее журналы.

rezedent12 ☆☆☆
() автор топика
Ответ на: комментарий от beastie

Ты ещё забыл температуру за бортом, а то, если слишком холодно, черти daemon'ы замёрзнуть могут.

Удивительно, однако в одной из моих старых серверных был управляемый привод на задвижку. И два термодатчика.
Если на улице холодно, а в помещении слишком тепло - задвижка приоткрывается. Этакий климат-контроль для бедных.

Вообще, по идее в инит-системе должен быть механизм регистрации источников событий. Мало-ли, вдруг libastral дорастет до стабильной версии?

kir2yar
()
Ответ на: комментарий от derlafff

Диск — это диск, а раздел — это раздел. Том — НЕХ, путаница и поэтому нафиг нужно.

Том - скорее более правильный термин, хотя спорно.
Вот смотри, у меня четыре диска, на каждом из них по разделу, разделы соединены lvm-рейдом 10 в один том.

Но для того, о чем говорит тот типус, есть устоявшийся термин - mountpoint.

kir2yar
()
Ответ на: комментарий от kir2yar

разделы соединены lvm-рейдом 10 в один том.

вот тут как раз том, да

derlafff ★★★★★
()
Ответ на: комментарий от kir2yar

Сокет-активация же ж. Плюс можно с udev'ом извратиться как-нибудь, если драйвер посылает change-события и соответствующим образом меняет атрибуты.

intelfx ★★★★★
()

Том. Проверка наличия подключенного тома с определённым UUID или меткой

когда у нескольких томов один и тот же UUID, прожуёт?

n_play
()
Ответ на: комментарий от derlafff

Диск — это диск, а раздел — это раздел. Том — НЕХ, путаница и поэтому нафиг нужно.

как в твоём понимании называются iscsi вольюмы? lvm? md?

n_play
()
Ответ на: комментарий от intelfx

Спалился!

создаешь md и вуаля. У всех «сущностей в нёё входящих» один и тот же uuid

uuid - это именно и есть локальная характеристика «блочной» сущности. Т.к. сущности входящие в raid впринципе одинаковы по содержимому (или должны быть), то и имеют один и тот же uuid.

n_play
()
Ответ на: комментарий от n_play

И по этому поводу у разработчиков udev достаточно большой баттхёрт, если я не ошибаюсь. Потому что UUID — это в первую очередь UU, и уже только потом ID.

intelfx ★★★★★
()

Какие события должна поддерживать система инициализации? И что она должна уметь?

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

3. Монтирование.

4. Управление сессиями.

5. Отслеживание событий на железе (особенно актуально для USB).

6. Управление питанием.

7. Синхронизация времени.

8. Предоставление сетевого доступа для администрирования (желательно в виде VNC).

9. Системный журнал.

10. Возможность переноса необходимой информации без переписывания её вручную (например, QR-коды).

11. Вебсервер.

12. Управление системой печати.

13. Управление звуковой системой.

14. Управление драйверами.

15. Системная шина IPC (в частности нужна реализация dbus).

16. Клиент и сервер ntp.

17. Минималистичная стандартная библиотека C.

18. Интегрированная поддержка kexec.

19. Интеграция с загрузчиком системы.

20. Запуск сервисов.

21. Супервизор сервисов.

22. В перспективе интеграция с ядром в виде кода в ядре.

Quasar ★★★★★
()
Ответ на: комментарий от Quasar

обязательно нужна поддержка TFTP и

Было-бы не плохо иметь recovery-ssh. И sftp. Разумеется отключенными по дефолту. За одно будет весело смотреть, как будут стенать лоровские хомячки. «ААааа!! Системд опенссш съел!»

собственного репозитория юнитов.

!!! Идеально! Давно следует сделать!
Будет что-то вроде python-pip. Дистронезависимое.

kir2yar
()
Ответ на: комментарий от kir2yar

kir2yar> Было-бы не плохо иметь recovery-ssh. И sftp. Разумеется отключенными по дефолту.

recovery-ssh как раз по дефолту включить надо. Если система навернётся, когда ж ты включишь этот шелл?

Quasar ★★★★★
()
Ответ на: комментарий от Quasar

recovery-ssh как раз по дефолту включить надо. Если система навернётся, когда ж ты включишь этот шелл?

Если система до конца не запустилась, то нужно запускать recovery-ssh.

kir2yar
()
Ответ на: комментарий от Chaser_Andrey

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

intelfx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.