LINUX.ORG.RU

systemd — новый подход к инициализации системы

 , , smf, ,


2

2

Lennart Poettering, сотрудник компании Red Hat, представил концепцию принципиально нового механизма управления инициализацией системы — systemd (system daemon), которая вобрала в себя достоинства классического System V init и более современных launchd (Mac OS X), SMF (Solaris) и Upstart (Ubuntu, Fedora), но при этом лишена многих их недостатков. В разработке этого проекта ему помогали сотрудники Red Hat, Novell, IBM, Intel и Nokia.

systemd опирается на современные linux-технологии: cgroups, AutoFS, D-Bus, и при этом совместим с исторически устоявшимися механизмами: init-скриптами, стандартными командами shutdown, poweroff и т.п. Предоставляемый systemd функционал позволяет заменить не только систему инициализации, но и ряд других подсистем, в частности, cron, (x)inetd, xdm/kdm/gdm/..., частично даже SELinux.

Основные идеи, использованные при создании systemd:

  • Контроль над сокетами. Многие демоны, запускаемые при инициализации, взаимодействуют с другими демонами через unix domain и сетевые сокеты, и большинство существующих систем инициализации запускают демона-клиента только после того, как демон-сервер запустится и создаст сокет. Вместо этого, systemd создает сокеты, а затем запускает демонов, передавая им эти сокеты. Даже если демон-клиент запустится быстрее и начнет использовать сокет раньше сервера, ничего страшного не произойдет: его запрос будет буферизован и передан серверу, как только тот сможет его обработать. Такой подход уже используется в Mac OS X (launchd), позволяя этой ОС достигать впечатляющей скорости загрузки.

    Аналогичный принцип используется systemd и при запуске служб, использующих шину D-Bus.

    Кроме того, возможен автоматический запуск служб при обращении к заданным сокетам (см. ниже).

  • Фоновое монтирование. Такие операции, как монтирование, проверка и активация квот файловых систем, занимают весьма значительную долю загрузочного времени. В большинстве современных систем они выполняются последовательно, до запуска всех демонов. systemd же предлагает монтировать не-жизненно-важные ФС только тогда, когда они кому-то понадобятся. Для этого используется механизм AutoFS. Например, многие служебные демоны вовсе не обязаны ждать, пока смонтируется огромный и к тому же зашифрованный /home.

    Разумеется, этот подход неприменим к /, /proc, /sys и т.п.

  • Минимизация числа вспомогательных процессов. В настоящее время значительная часть работ по инициализации производится шелл-скриптами, что приводит к колоссальным времязатратам. В частности, Леннарт пишет:

    On my system the scripts in /etc/init.d call grep at least 77 times. awk is called 92 times, cut 23 and sed 74,

    при этом замечая, что почти каждый такой запуск влечет накладные расходы на поиск библиотек, подгрузку данных интернационализации (i18n) и т.п.

    В качестве альтернативы Леннарт предлагает предлагает переписать критичные участки на C, а также вынести часть функционала в самих демонов и в systemd. Сейчас для systemd уже готовы написанные на C подсистемы монтирования и установки имени хоста. До полной победы, отмечает Леннарт, работа предстоит огромная, но результат того стоит.

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

    Для предотвращения таких ситуаций systemd использует интегрированный в ядро Linux механизм контрольных групп (cgroups). Если приложение не имеет доступа к псевдо-ФС, управляющей работой cgroups, то оно не может самостоятельно покинуть свою группу и «потеряться».

    Также к этой группе задач относится и автоматический перезапуск демонов, перенаправление их stdout/stderr на выбранные TTY или в системный журнал, регистрация всех запусков и остановок служб, и многое другое.

  • Ограничение процессов. systemd предоставляет множество возможностей ограничить или расширить полномочия процессов, контролируя такие параметры, как uid, gid, umask, рабочий и корневой каталоги, класс и приоритет CPU и I/O, наличие доступа на чтение и запись к смонтированным файловым системам и отдельным каталогам и т.п. Также можно использовать возможности по ограничению ресурсов, предоставляемые cgroups.

Базовым элементом systemd являются модули (units), которые связаны между собой и имеют определенный тип. Каждый модуль может требовать для своей работы другие модули, конфликтовать с модулями, запускаться только после или до определенного модуля (директивы конфигурации Requires, Conflicts, Before, After, Wants). Из типов модулей определены:

  • service — обычный демон, поддерживающий операции start, stop, restart, reload. Может быть представлен родным (native) файлом конфигурации systemd или System V init-скриптом.
  • socket. При обращении к сокету генерируется событие, для которого можно настроить обработчик. Например, автоматически запускать определенные службы при обращении к заданному сокету. В этом отношении systemd похож на давно известный (x)inetd, однако при этом поддерживает unix domain сокеты и FIFO.
  • device. Отметив нужные устройства в конфигурации udev, впоследствии можно использовать такие события, как появление и удаление устройства, в качестве событий systemd, назначив на них обработчики. Например, при появлении устройства bluetooth будет запущена соответствующая служба.
  • mount. systemd контролирует все точки монтирования файловых систем. В целях обратной совместимости поддерживается сбор информации о точках монтирования из /etc/fstab.
  • automount. Для помеченных таким образом точек монтирования, монтирование выполняется только при обращении к ним.
  • target. Более гибкий аналог уровней исполнения (runlevels), используемых в System V init. Представляет собой группу служб, объединенных по функциональному назначению. Например, multi-user.target идентичен runlevel 5, а bluetooth.target приводит к инициализации подсистемы bluetooth.
  • snapshot — во многом похож на target. Позволяет «запомнить» существующую конфигурацию units (запущенных служб, открытых сокетов, смонтированных ФС) с тем, чтобы в дальнейшем восстановить это состояние. Позволяет, например, перейти в emergency shell (сейчас это init 1), а затем полностью восстановить набор запущенных служб. Другой пример — выход системы из состояния suspend.

Надо заметить, что systemd отличается от SMF, во-первых, тем, что позволяет оперировать не только зависимостями между службами, но и событиями, например, «готовность устройства» или «обращение к сокету». Во-вторых, systemd использует более простой формат файлов конфигурации (.desktop aka .INI против XML в SMF).

От upstart же systemd отличается более высокой степенью параллелизации, и как следствие, более высокой скоростью загрузки. Например, если демон A требует для работы сокет, открытый демоном B, то upstart сначала запустит демона B, а затем демона A, в то время как systemd создаст сокет сам и запустит обоих демонов одновременно, что занимает примерно в два раза меньше времени. Используемый в upstart принцип, когда ключевыми событиями является лишь запуск и остановка демона, Леннарт и его коллеги считают изначально неэффективным.

Well, the point of the part about Upstart above was to show that the core design of Upstart is flawed, in our opinion. Starting completely from scratch suggests itself if the existing solution appears flawed in its core. However, note that we took a lot of inspiration from Upstart's code-base otherwise.

>>> Подробности

★★★★

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

Ответ на: комментарий от Legioner

Я бы предожил такой подход: Модули пишутся на некоем относительно высокоуровневом языке, на котором их удобно писать, который включает в себя часто используемые конструкции. Далее все модули компилируются в исполняемый код (вероятно в С, потом в исполняемый код). И полученный монолит выполняется при старте. Каждый модуль отдельно может быть интерпретирован, что может быть полезно для отладки. При хорошей реализации выше скорости достичь будет практически невозможно, есть возможности управления какими угодно зависимостями, событиями, автостартами, и прочим.

Сила (и превлекательность) линукса как раз в скриптах, в возможности просто, быстро и не затратно по времени написать свой демон с помощью того же vi. Бинарные демоны, а'ля винда конечно быстрее работают стартуют, но мне лично возможность просмотреть «а как оно устроено» прямо здесь и сейчас важнее, чем пара десятков секнд времени при загрузке десктопа. Про сервер я вообще молчу. Так что Си - не катит вообще никак.

Что же до Р-кода, то такие предложения были и не раз. В принципе да, неплохо писать скрипты мммм... ну хоть бы и на пистоне, поскольку пистон их автокомпилет в р-код, а уж тот выполняется куда быстрее чем интерпретируется текст. Но пока к несчастью, питоновцы жутко заняты переходом на тройку и вряд ли пока способны дать что либо миру сидя на чемоданах.Про остальных говорить не буду, но я вот что-то никого из кандидатов не вижу кроме жабы, а с ней мне например как-то не очень охота дружится, после того как с ней «задружился» оракл.

k0valenk0_igor ★★★
()

Мало информации в новости, не понятно о чем речь...

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

> Для того чтобы работало очевиджное невероятное - надо чтобы была _полная_ превалидация кодфига, чтобы не вылетел какой нить банальный atoi, чего не надо было делать для скриптов с интерполяцией переменных и подобными вещами.

А что, отсутствие проверки на ошибки делает скрипты надёжнее?

очевидным невероятным результатом скорее всего станет segfault. Или огромная работа в написании «инициализаторов» чтобы от сегфаултов защищаться.

Школьник что-ли?.. Или тролль?

Остальные-то программы на C как пишут? Считаешь, их разработчики тоже всего безумно боятся и думают «как же, как же будет работать наша прога, если мы прочитаем строку букв вместо числа?»? «Волков бояться - в лес не ходить».

А вообще лично я сомневаюсь что переписывание на С разгонит хоть что-то. Для этого надо доказать что именно интерпретация bash тормоз системы. Пока это не доказано ниразу.

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

ximeric
()

Помню, даже пробовал свой инит на сях писать.. Само ядро (очень) быстро бутается..

anon_666
()

Кое какие идеи изложенные не плохи, но в целом концепция неверная.

Во первых, одного высокоэффективного и мощного демона сподручнее разрабатывать и поддерживать одной отдельно взятой компанией. Не спроста что-то подобное сперва в винде появилось и в маке. У нас же скорее всего не прокатит: чревато ошибками и разбуханием кода. Может получится как с ядром, но только гораздо печальнее.

Кроме того сильно страдает аспект безопасности: есть что-то гнилое в демоне, который и в системе «впереди планеты всей» и безопасность еще и контролирует и вообще.... Шаг к супер-руткитам, после которых линух будем лечить initfs'ом?

Ну и наконец, мне лично важно что бы система быстро работала, а не быстро стартовала. И многие, я знаю, думают как и я. Так что, поделие может и сгодится... для нетбуков и каких-нито еще смартфонов. Для дсктопов - вряд ли.

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

> там запуск через /etc/udev/rules.d

Ну а если там работает через правила udev, зачем это вообще приплетать? Здесь как бы другую службу обсуждают.

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

> У нас в общаге количество стационарных компов уже точно не 50%. Намного меньше. Ноут нужно бысть включить, поработать и быстро выключить

Вы выклюбчаете ноут? Suspend/Hibernate опять сломан? >_<

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

>А что, отсутствие проверки на ошибки делает скрипты надёжнее?

Большинство ошибок часто не являются ошибками в принципе - они ошибками являются только постольку поскольку их считает таковыми интерпретирующая система. Для передачи параметра команде в шеле фраза в конфиге типа PORT=8000 не говорит например что 8000 это число - это монопенисуально если все что будет делаться это /bin/daemond $PORT. В случае кода на С тебе нужно будет распарсить эти 8000 в число чтобы передать его в вызов соответствующей функции. Это банально тащит за собой кучу кода например валидации конфига который нужен только потому что пишется на слишком низком уровне. Это тебе пример про уровни абстракции которые делают любую программу надежднее.

Школьник что-ли?.. Или тролль?


Аналог cp $SRC $DST на с в студию. Посмотрим кто троль.

Остальные-то программы на C как пишут?


так чтобы один раз написать cp в бинутилсах и всегда использовать его из shell, а не из С. Само наличие кучи «програм на С» которые используют в суперкомпозиции типа шела говорит о том что на С писать то что пишется на шеле - это ужос.

Считаешь, их разработчики тоже всего безумно боятся и думают...


Их разработчики давно придумали sed,awk,expr,test и прочий бинутилс чтобы _не писать этого на С_.

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


Количество вспомогательных процессов можно минимизировать не только на С. Более того - С - это худший вариант.

И обрати внимание на свою же фразу «интерпретация bash тормоз системы», ключевое слово «интерпретация».


Как думаешь при вызове командочки mount в шеле - что сьедает больше всего времени: интерпретация этой команды шелом, запуск чайлдового процесса или собственно монтирование (написанное между прочим на С)?



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

>> DSL вроде расширенного баша с абстракциями зависимостей, приоритетов.

По-моему, дело написано.

Ерунда написана. DSL, может, и нужен, но только для описания графа зависимостей между службами. «Расширенный баш», my ass. Это такая хрень, которая сложнее самого баша?

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

Ну для начала надо решить что нужно, у меня при «расширенном баше» несколько иное пред глазами пролетело. Возможно, мне приглючилось.

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

> Ну для начала надо решить что нужно

Граф зависимостей. Но, подозреваю, он в том или ином виде есть и в upstart.

у меня при «расширенном баше» несколько иное пред глазами пролетело

А что еще могло пролелтеть перед глазами, кроме «программа, которая умеет всё, что баш, но еще и <блабала>»? :)

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

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

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

> А вообще лично я сомневаюсь что переписывание на С разгонит хоть что-то. Для этого надо доказать что именно интерпретация bash тормоз системы. Пока это не доказано ниразу.

Позволю себе не согласиться. На моём компьютере вполне доказано - вынос из скриптов инициализации всего закомментированного содержимого и всех проверок типа «if [ -x чего-то там ]; then» (знаю, что ССЗБ может случиться - но на этот случай есть резервные копии исходных скриптов) вокруг незакомментированных команд дал мне выигрыш секунд в 25-30 минимум. Комп старый - поэтому так много, но зато наглядно.

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

> А что еще могло пролелтеть перед глазами, кроме «программа, которая умеет всё, что баш, но еще и <блабала>»? :)

Ну вначале стояло ведь «DSL», так что у меня промелькнуло не это.

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

кстати, сейчас в линуксе чтобы перезапустить отвалившийся процесс нужно ставить систему мониторинга или есть штатное системное средство для этих целей?

Как водится, есть _несколько_ штатных средств определения, жив ли процесс, и (пере)запуска сервиса при необходимости. Например, monit Следует только понимать, что жизнеспособность сервиса - это не только и не столько запущенный процесс, сколько корректно работающий процесс, поэтому относить такой мониторинг целиком на уровень ядра нежелательно и нереально.

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

>2. Ждём реестр вместо /etc в качестве третьего проекта автора.

Это ты слишком просто взял. Он его обединит с ifxxx и dbusом - чтобы можно было по изменению значения в реестре с 0 на 1 поднимать и опускать интерфейсы или передавать командочки демонам.

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

>Расширенный баш", my ass. Это такая хрень, которая сложнее самого баша?


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

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

>вынос из скриптов инициализации всего закомментированного содержимого

Комп старый - поэтому так много

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

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

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

Ну если бы вы не придирались, а внимательно прочитали всё сообщение - то поняли бы, что основной выигрыш как раз на проверках. Комментарии убраны для читабельности, в основном - зря их упомянул, наверное. Ж;-)

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

>Ну если бы вы не придирались, а внимательно прочитали всё сообщение - то поняли бы, что основной выигрыш как раз на проверках. Комментарии убраны для читабельности, в основном

Сами перечитайте, на читабельность там и намека не было ;) И «основной выигрыш» тоже как бы говорит, что и на комментариях что-то ощутимое есть. Конечно придираюсь :)

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

> моя засыпает и просыпается очень быстро.

Ну, когда она засыпает - это здорово. А вот мой свежесобранный домашний десктоп в s2m уходить не желает, видимо, набортный USB3.0 контроллер ещё не поддерживается (Device usb8 failed to suspend при отсутствующих USB-дивайсах). Так что, либо s2d (что уже совсем, совсем другие времена), либо полное выключение. И когда комп используется как эдакий домашний «центр развлечений», то время загрузки становится важной составляющей мягких и шелковистых волос... И, кстати, сразу после установки 10.04 s2d в списке отсутствовал...

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

> вынос из скриптов инициализации всего закомментированного содержимого и всех проверок типа «if [ -x чего-то там ]; then» (знаю, что ССЗБ может случиться - но на этот случай есть резервные копии исходных скриптов) вокруг незакомментированных команд дал мне выигрыш секунд в 25-30 минимум

У меня Debian 5.0 на встроенной плате с 300МГц PowerPC грузится до логина (консольного) меньше минуты (при том, что там JFFS2 с компрессией). Что за музейная железка у тебя?

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

>Ты думаешь, что программисты есть не хотят?
Хотят? хотят тока одним платят золотые горы но у них все равно просвета в голове так и не случается и заканчивают они как Мигель - в Редмонде, а другие забесплатно как анастезиолог Коливас могут в одиночку делать что то серъезное. Так что как видишь проблема все таки в мозгах. И если гения отправить зарабатывать деньги почему то все начинают думать что это он написал потому что ему платят дофига.

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

> «Медленно» - это не от того, что bash и coreutils медленные, а оттого, что скрипты ждут чего-то, причем этом запускаются последовательно.

Ждут они друг друга. И это неизбежно, когда все средства взаимодействия между «задачами» сведены к «запустить внешнее приложение-дождаться файла/выхлопа».

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

>> «Медленно» - это не от того, что bash и coreutils медленные, а оттого, что скрипты ждут чего-то, причем этом запускаются последовательно.

Ждут они друг друга. И это неизбежно, когда все средства взаимодействия между «задачами» сведены к «запустить внешнее приложение-дождаться файла/выхлопа».

И это правильно. Другое дело, что скрипты инициализации разных служб можно пускать в параллель, если известен граф зависимостей.

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

... Это банально тащит за собой кучу кода например валидации конфига который нужен только потому что пишется на слишком низком уровне.

Что-то вообще не вижу проблему. Откуда куча кода? Берём готовую библиотеку и используем.

Аналог cp $SRC $DST на с в студию. Посмотрим кто троль.

Копировать сюда не буду, ищи на страницах http://www.opennet.ru/docs/RUS/bogatyrev/ex_12.html или http://rus-linux.net/MyLDP/BOOKS/bach/glava_5.htm.

Во-первых, приведи пример необходимости копирования файлов в процессе инициализации системы. Во-вторых, не нужно отрывать свою же фразу, на которую я дал тебе такую характеристику. А получил ты её потому, что пытаешься усложнить очевидные вещи.

Как думаешь при вызове командочки mount в шеле - что сьедает больше всего времени: интерпретация этой команды шелом, запуск чайлдового процесса или собственно монтирование (написанное между прочим на С)?

Не буду гадать.

# time mount /var/xxxxxxx/xxxxx
real    0m0.143s
user    0m0.002s
sys     0m0.005s
Сам-то ты как думаешь? ;-)

И не нужно мешать в одну кучу мух и котлеты.

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

> У меня Debian 5.0 на встроенной плате с 300МГц PowerPC грузится до логина (консольного) меньше минуты (при том, что там JFFS2 с компрессией).

Ну до консольного у меня тоже меньше минуты, наверное - до X'ов где-то 1:15 после чистки ненужных демонов и проверок. До чистки Fedora грузилась примерно за 2:15-2:20, Slackware побыстрее немного.

Железка не вполне музейная - PIII 1,4 ГГц.

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

> Сами перечитайте, на читабельность там и намека не было ;)

Некорректность формулировки. Полагаю, что закомментированное само по себе дало мне не больше секунды (ну, или двух). Ж;-)

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

И почему это правильно? Собственно говоря, в подавляющем большинстве случаев «баш» при запуске сервиса не нужен, обходятся же inetd/xinetd без баша в конфигах вовсе. Да я понимаю, бывают сложные, местами клинические случаи, когда нужен именно скрипт. Но это, скорее, исключения из правила. большая часть SysV-style init'ов - это определение, надо ли нам запускаться (привет /etc/{default,sysconfig}/XXX), определение, в каком режиме мы сейчас запущены (case $1 in in start)... ) и запуск соотв. демона.

AlexM ★★★★★
()

Маразм.

Лишняя минута ожидания - это смешно.

Те, кто говорят про встраиваемые системы, по-ходу, с ними никаких дел, вообще, не имели. Трындят чисто так. Во встраиваемых системах это поделие не актуально ни разу, т.к. там и рядом нет такой кучи демонов стартующих. И любой телевизор, если разраб с руками, будет чудесненько и быстренько запускаться с обычными стартовыми скриптами на bash.

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

>Что-то вообще не вижу проблему. Откуда куча кода? Берём готовую библиотеку и используем.

И что по отношению к запуску системы бытовая библиотека? И что есть такая бытовая библиотека которая например проверит /etc/sysconfig/network? Или таки придется попис`ать ручками?

Во-первых, приведи пример необходимости копирования файлов в процессе инициализации системы.


Жесть. Загляни в свой rc.d.

И ты что думаешь от ls или cat тебе станет легче?

И не нужно мешать в одну кучу мух и котлеты.


Именно что не надо.

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

> И почему это правильно?

А ты хочешь распараллеливания внутри одного init-срипта? O_o

обходятся же inetd/xinetd без баша в конфигах вовсе.

Для этих служб и init-скрипт был бы из одного case, но это вырожденный случай. А если нужно проверить конфигурацию системы, загрузить драйверы и.т.д?

большая часть SysV-style init'ов - это определение, надо ли нам запускаться (привет /etc/{default,sysconfig}/XXX

Вообще-то определинем, нужно ли пускать init-срипт сам init-скрипт не занимается.

определение, в каком режиме мы сейчас запущены (case $1 in in start)... )

Это определение, что нужно сделать - запустить сервис, остановить его или просто выдать статус.

Ты хоть смотрел на реальные init-скрипты? :)

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

> И любой телевизор, если разраб с руками, будет чудесненько и быстренько запускаться с обычными стартовыми скриптами на bash.

А если это не телевизор, а «почти generic» медиацентр, в котором и браузер открыть можно, и страничку на печать послать, и какой-нибудь торрент запустить.

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

> А ты хочешь распараллеливания внутри одного init-срипта? O_o

Я прошу прощения, где я хоть слово за распараллеливание сказал? Я всего лишь утверждал и продолжаю утверждать что bash для запуска демона как правило не нужен.

А параллельно запускать или перпендикулярно - это вопрос второй. Параллельный запуск - это тема интересная, но далеко не такая однозначная - при массовом параллельном старте на механических устройствах хранения упираемся в IO. Проверено на себе. Кстати, если меня не обманывает мой ставший постоянным склероз, в initng была настройка по ограничению сверху одновременно запускаемых сервисов. Как раз таки потому, что на данной конкретной машине быстрее оказывалось выстроить в очередь, чем шибануть все разом, из-за сильно ненулевого seek-time.

Для этих служб и init-скрипт был бы из одного case, но это вырожденный случай.

Он для бОльшей части сервисов такой, см. убунтячьи upstart'овые скрипты.

А если нужно проверить конфигурацию системы,

А это точно надо делать на каждом запуске сервиса?

загрузить драйверы и.т.д?

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

Вообще-то определинем, нужно ли пускать init-срипт сам init-скрипт не занимается

Ой, не мучайте меня. if [ «x$NETWORKING» = xno ]; exit <N>; fi Причём, специально подмонтировал раздел со свежеустановленной F13B, чтобы убедиться, что это не только в Альте такое практикуется. И это только один пример того, как прямо внутри стартового скрипта принимаются какие-то решения, надо запускать или не надо.

Это определение, что нужно сделать - запустить сервис, остановить его или просто выдать статус.

Спасибо за рассказку.

Ты хоть смотрел на реальные init-скрипты? :)

И вот в этом месте очень хочется ответить вопросом на вопрос... Но не буду, нельзя скатывать дискуссию до уровня сам дурак. Скажу лишь, что первую версию udev'овской обвязки для альта писал именно я.

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

У ред хата программистов в разы больше, как миниму эта причина. А ты давай дальше фапай на ред хат и отрицай достижение менее крупных игроков, можешь даже заслуги сообщества отрицать.

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

> Кстати, а не лучше bash JIT комплитятор какой написать

Лучше. А ещё лучше отказаться от бОльшей части баша, тогда и JIT получится существенно проще.

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

> есть так же RSCT от IBM

Слушай, а че ты AIX6 не назвался? А то Solaris10, а все про IBM да AIX... Рассказал бы чтоли про SMF да process contracts чтоли

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

>А ещё лучше отказаться от бОльшей части баша, тогда и JIT получится существенно проще.

Тогда уж лучше другой шелл с JIT (к тому же dash прикрутить), а баш не трогать.

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

Зрите в корень :) Немного выше я говорил про специализированный DSL или, на крайний случай, урезанный perl/python/javascript со специализированным набором библиотек, чтобы конфигурировать и поднимать сервисы.

AlexM ★★★★★
()

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

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

Хорош? Ню-ню... Как в этом вашем хвалёном БСД-ините реализовать без костылей зависимости сервисов? Как запустить апач строго после мускуля?

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

А что, у вас ещё не уехали массово на initng? Или уже обратно приехали? :)

P.S. BSD-lovers, загляните в /usr/local/etc/rc.d . Сильно удивитесь :)

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