LINUX.ORG.RU

Ковыряю тут s6 в artix, и вопросы у меня, архитектурного свойства...

 , ,


0

2

Вопрос раз. Идея, что большая часть работы PID1 выполняется в early init (stage1) и shutdown (stage3), и весь этот код не нужен в аптайме (stage2) – очень толковая. Идея реализации этого принципа через три разных процесса, переход между которыми – тупо exec() без fork() – шикарная. Т.е. все три процесса имеют PID1. На stage1 работает s6-linux-init, на stage2 – лёгкий s6-svscan, и их функционал не пересекается. А вот с shutdown ЯННП:

1.1. Схренали в stage2 (т.е. весь аптайм) висит supervised-демон s6-linux-init-shutdownd? Прямо нарушая всю идею.

1.2. Схренали ли скрипты /run/service/.s6-svscan/{crash,finish} оба вызывают s6-linux-init-hpr -fr (forced reboot)? Т.е. получается, что в модели «exec() следующей stage из предыдущей» stage3 – это не shutdown, а исключительно мгновенный ребут в случае падения, а логический shutdown выполняется в рамках stage2.

1.3. Схрена ли s6-svscan по SIGTERM сначала останавливает супервизоры (и управляемые ими процессы), дожидается их завершения – и опять-таки проваливается в finish т.е. в forced reboot. Чем это отличается от shutdownd? Ну наверное можно найти чем: shutdownd вызывает /etc/s6/current/scripts/rc.shutdown, который вызывает s6-rc (полагаю, для остановки сервисов; доки подсистемы s6-rc ещё не читал). Т.е. по идее это более «корректная» остановка сервисов, чем тупо остановка long-running процессов, но всё равно ощущается как задвоение функционала с shutdownd.

1.4. И отсюда: почему нельзя было сделать так, чтобы по SIGTERM s6-svscan exec()-ался не в {crash,finish}, а в какой-нибудь другой скрипт, выполняющий честный stage3 (shutdown / halt / reboot), с вызовом s6-rc и всё такое?

Вопрос два. Аргументация, что /sbin/init должен быть сверхмаленьким и сверхнадёжным, – логична. Но: тут же этот s6-svscan под тем же рутом поднимает кучу процессов s6-supervise – по одному на сервис (точнее на long-running supervised process). Отсюда сразу две непонятки:

2.1. Схрена ли нельзя было все сервисы обслуживать одним супервайзером?

2.2. Схрена ли нельзя было объединить s6-svscan и s6-supervise, раз уж они один хрен все под рутом. (Впрочем, на эту тему автор что-то писал: мол, даже если супервайзер какой-то подохнет, PID1 останется жив. Но я не уверен, насколько это серьёзная аргументация.)

Вообще, я выбрал s6 т.к. повёлся на манифест его автора «нахрена ещё одна init-система», и может быть когда-нибудь в итоге даже и порадуюсь – мол какой я умный, разобрался и даже без 66 обошёлся. Но пока что чёт страшновастенько как-то…

Перемещено alpha из admin

★★★★★

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

Artix не читал, но… C s6 давно не работал, поэтому неправда. Пишу по памяти.

Stage1 (s6-linux-init) генерирует/подготавливает окружение для stage2.

s6-linux-init-shutdownd - нормальный сервис, допустим для корректного выключения, можно, например, навешать зависимостей на него - одноразовые сервисы, которые сработают при выключении.

Раз есть сервис, отвечающий за корректное выключение, то почему бы crash и finish - это ненормальная ситуация, как и stage3.

s6-rc - это генератор директории сервисов (для svscan, stage2).

svscan - это корень (под)списка сервисов. Можно строить дерево из них, например, для каждой пользовательской сессии свой svscan (аналог systemd –user)

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

s6-linux-init-shutdownd - нормальный сервис, допустим для корректного выключения, можно, например, навешать зависимостей на него - одноразовые сервисы, которые сработают при выключении.

Раз есть сервис, отвечающий за корректное выключение,

Вот собственно в том и вопрос: нахрена сервис, отвечающий за выключение, висит в памяти весь аптайм, а не работает исключительно в stage3? Одноразовые зависимости тут не противоречат – один хрен все они будут выполняться только при остановке.

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

Не знаю, artix ни разу в жизни не видел. Может, этот сервис - обработчик ctrl-alt-del, или другой комбинации, или ждет пока сигнал kaput не пошлют в пайп.

И вообще, s6-rc - это хитрый генератор, может нагенерить всяких разных «служебных» сервисов.

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

Про то что rc генерит каталоги сервисов – это понятно. Но shutdownd лежит в /etc/s6 вне rc. И задокументирован он в подсистеме s6, не s6-rc. Так что непонятка пока что осталась.

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

shutdown могла бы тупо слать SIGTERM в svscan (а не в shutdownd), по которой он exec()-ал бы соответствующий stage3-скрипт (вместо finish).

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

Для shutdown можно указать время и отменить. Например, для этого. В общем, написано, что так надо, значит надо.

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

Для shutdown можно указать время и отменить. Например, для этого.

Хм. Ок, принимается как обоснование того, что shutdownd должен работать в stage2. Но тогда запускать его достаточо было бы только командой shutdown, а при отмене – останавливать если запущен. Т.е. сидеть в памяти ВЕСЬ аптайм – опять же не нужно.

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

Сдаюсь, лохматый. Я так зашел, поговорить. :)

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

Но тогда запускать его достаточо было бы только командой shutdown, а при отмене – останавливать если запущен.

Более того, это тогда был бы не shutdown-демон, а демон-планировщик, т.е. просто отложенный таймер перехода в stage3.

dimgel ★★★★★
() автор топика

Вообще, это вопрос больше про системное программирование, а не про администрирование. @alpha, перекинь плиз в Development?

UPD. Сенькс. :)

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

Приехал ответ от автора на вопрос 1. Т.к. разрешения копипастить я не спрашивал, кратко пересказываю:

Первые версии s6-linux-init (0.x) работали как я написал. Но (1) для совместимости с sysvinit (в т.ч. для поддержки всех этих опций shutdown, о чём аноним выше написал) оказалось проще держать s6-svscan как PID1 всё время, в т.ч. в stage3. Если мне пох на эту совместимость, я могу переопределить любой из сигналов в /run/service/.s6-svscan, но (2) останутся проблемы в stage4: после kill -9 -1 нужно чтобы кто-то подхватил управление, выполнил unmount all и выключил машину. Всё это было слишком хрупким; сервис shutdownd гораздо надёжнее. См. также https://skarnet.org/lists/supervision/2777.html

dimgel ★★★★★
() автор топика
Последнее исправление: dimgel (всего исправлений: 2)

По поводу отложенного запуска shutdownd: запуск сразу – проще код; надёжней (если нужно остановить систему из-за OOM, то отложенный shutdownd может и не запуститься из-за OOM); затраты по памяти незначительны; и можно поменять права на пайп, чтобы дать обычным юзерам возможность вызывать shutdown. Кроме последнего аргумента, всё это я и сам сообразил, но вот оценить относительную весомость тех или иных аргументов уже не смог бы: нет практики разработки таких вещей. «The difference between theory and practice…»

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