Я тоже не смог осилить написать пример на s6.

для systemd ещё сложнее

Выше я написал.

until printf «» 2>>/dev/null >>/dev/tcp/foo.socket; do sleep 1; done; foo-service

А как это работает, кто создал /dev/tcp, /dev/tcp/foo.socket? Если юнитов десятки, то будут десятки циклов висеть в процессах?

Выше я написал.

Возьми с полки пирожок.

А как это работает, кто создал /dev/tcp, /dev/tcp/foo.socket?

Да ё моё, дайте КОНКРЕТНУЮ задачу. В твоём примере я тоже не понимаю, как это работает.

Если задача «сделать так же, как это работает в systemd», то я для этого мне придётся разобраться, как это работает в systemd. А я не знаю, я никогда юнитов с активацией по сокету для него не писал, и знать не знаю, как именно она работает, и кто там их создаёт, или они должны быть заранее созданы.

Если юнитов десятки, то будут десятки циклов висеть в процессах?

Да, будут. Но мне сложно представить такое «если». И один-то такой, где это нужно, найти бы, а тут десятки… Но если их десятки — да, будет десяток процессов, которые ничего не делают. Никаких проблем в этом нет.

Да ё моё, дайте КОНКРЕТНУЮ задачу. В твоём примере я тоже не понимаю, как это работает.

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

Да, будут. Но мне сложно представить такое «если». И один-то такой, где это нужно, найти бы, а тут десятки… Но если их десятки — да, будет десяток процессов, которые ничего не делают. Никаких проблем в этом нет.

Я подумал что может быть удобно мне, например начал работать, весь LAMP поднялся, закончил, по таймеру от бездействия само все остановилось, не надо каждое утро делать systemctl start и каждый вечер systemctl stop.

ок, понял. Не ожидал, что нам ещё и создать сокет надо, а не наоборот… Нет, я не знаю, как именно это реализовать по ранее предложенному принципу с циклом. И мне лень разбираться в том, что мне никогда не требовалось и, надеюсь, никогда не потребуется. Так что сдаюсь, не напишу.

Тут не очень понятно, нафига оно в таком виде вообще, если не кто-то другой и не сам демон сокет создаёт, а инит, причём для конкретно демона, но при этом должен уметь с таким типом активации работать и из этого сокета читать. Почему просто не запустить демон, чтоб он себе создал сокет какой нужно, а когда прилетели данные, не развернул весь процесс, почему это надо было вынести в инит?…… Хотя кажется, я начинаю понимать: docker — это же продукт RedHat тоже. Не удивительно, что они свой же docker решили завязать на свой же systemd.

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

Это означает что в программе которая «туда подключается» должен быть либо реализован какой-то костыль для передачи дескриптора уже открытого и законнекченного сокета из системде в программу, либо, как минимум использование stdin/stdout вместо сетевого сокета, как это было сделано в inetd со всеми вытекающими (отдельный процесс на каждый коннект, например).

Т.е. произвольную сетевую софтину, которая специально не заточена под костыли системде просто не получится «активировать по сокету» используя системде. :) Офигительно полезная фича, да…

Для программ которые это не поддерживают есть systemd-socket-proxyd

Хотя кажется, я начинаю понимать: docker — это же продукт RedHat тоже. Не удивительно, что они свой же docker решили завязать на свой же systemd.

А когда он успел им стать? Я чего то не знаю? Разве у них не podman?

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

И к каждой программе такого демона дописывать?

А когда он успел им стать? Я чего то не знаю? Разве у них не podman?

Да, действительно не их, но они вроде как участвуют.

September 19, 2013: Red Hat and Docker announced a collaboration around Fedora, Red Hat Enterprise Linux (RHEL), and OpenShift.

И к каждой программе такого демона дописывать?

Зачем? Демон же уже есть, по условию задачи, ради него всё и делается. Ему просто можно висеть в виде очень маленького кусочка, который слушает сокет, а потом догружает остальное, когда надо.

В чём причина, что Runit не распространён, как Systemd?

Нишевый, для гиков. Мало фич, нет системы зависимости служб.

Смотри - есть например софтина, которая умеет открыть TCP сокет типа 0.0.0.0:12345 и делать accept запуская треды для этих соединений и делая разное в зависимости от того какой remote адрес, во что он обратно резолвится, есть ли в DNS для этого домена запись специальная и что в ней и т.п.

Как твой systemd-socket-proxyd поможет сокетно активировать эту софтину? Или ты предлагаешь запускать софтину на 127.0.0.0:54321 и поломать к едрене фене всю логику работы софтины своей проксей? :)

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

я хз, чо оно там делает, я всегда говорил не трогайте OpenRC и Патрик тоже не против

Если самый массовый линукс инит - Upstart, то ничего не мешает, кроме желания той или иной корпорации

В systemd написать сервис активируемый по сокету проще. Форк процесса с использованием systemd с последующим ожиданием чем-то существенно отличается от runit? А такое в systemd тоже делают. Кто должен создать сокет? Runit, init тоже умеет запускать сервис по сокету, это не ново.

Вот это, кстати:

если что-то где-то происходит, то легко понять, что и где. В общем, основное достоинство — простота (при полноценном выполнении возложенной задачи).

Про systemd

Можно просто сделать скрипт-обёртку docker, которая будет запускать докер, если он не запущен, и выполнять команду, а если уже запущен — просто выполнять команду. Не нужно городить сложности вокруг простых вещей.

Что может быть проще docker ps?

оторая длиннее по объёму, чем скрипт (не для sysv, там правда ужас был), которую при этом сложнее написать и сложнее прочитать.

  [Unit]
    Description=Docker Application Container Engine
    Documentation=https://docs.docker.com
    After=network.target docker.socket
    Requires=docker.socket

    [Service]
    Type=notify
    ExecStart=/usr/bin/docker daemon -H fd://
    LimitNOFILE=1048576
    LimitNPROC=1048576

    [Install]
    Also=docker.socket

¯_(ツ)_/¯

Вот как в руните сделать ежедневный таймер с логгированием и ротацией логов?

Проблема в том, что это не должно быть задачей init. А так вагон вариантов с syslog, logrotate, cron.

В системд все из коробки работает.

Комбайн...

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

В теории. Только в теории. И ещё вопрос, что такое «обычная».

Как-то все забыли, что systemd принес ПАРАЛЛЕЛЬНУЮ загрузку сервисов, что весьма даже ощутимо сократило время начального старта системы. в sys-v и runet, как мне помниться, загружают сервисы ПОСЛЕДОВАТЕЛЬНО, что сильно больше по времени, не говоря, что в разных конкретных инсталяциях Linux, даже одного дистрибутива, могут быть установлены разные сервисы, и соответственно, заранее крайне затруднительно определить порядок запуска. В массовом обслуживании, затруднительно приставит к каждому компу по квалифицированному админу.

Как ни странно, systemd - во многом снимает эти очень больные для эксплуатанционщиков вопросы.

Плюс стандартизация/унификация процессов запуска системы, облегчает жизнь разработчиков сервисов, ибо им не нужно разбираться с нюансами запуска на каком-либо «экзотическом» дистрибутиве…

Так что это все, с моей точки зрения, и позволило systemd - стать лидером - с ним в эксплуатации получается банально дешевле…

Почему тогда rpm не так распространен?

Проделки космонавта. Я до убунты на deb и не смотрел.

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

в sys-v и runet, как мне помниться, загружают сервисы ПОСЛЕДОВАТЕЛЬНО, что сильно больше по времени, не говоря, что в разных конкретных инсталяциях Linux, даже одного дистрибутива

Параллельно они грузятся в runit. Тут скорее наоборот в systemd фишка в том, что он позволяет последовательно (After, Before) в определённом порядке, а в простых это не фича самого инита, а нужно сделать проверку на запущенность другого демона, если твой от него зависит.

что сильно больше по времени, не говоря, что в разных конкретных инсталяциях Linux

Одинаково оно, даже было. Но SSD убрал все остатки разницы между тем, как грузить «сервисы». Вне зависимости от инита, грзятся они обычно 3–7 секунд, в зависимости от количества и сложности, а основное время занимает ожидание монтирования носителей и подключения к сети (ещё столько же, если не больше).

то создал /dev/tcp, /dev/tcp/foo.socket

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

кому и баш-портянка не сложно :)

Вот как в руните сделать ежедневный таймер с логгированием и ротацией логов?

а как в системд сделать g-code из 3д модели для печати на 3д принтере?

Используй systemd-gcoded

Как ни странно, systemd - во многом снимает эти очень больные для эксплуатанционщиков вопросы.

Начать с того, что это в принципе вопрос, который не стоит выеденного яйца. В нормальной десктопной системе аптайм измеряется десятками дней. Если это ноут (ибо гибернация) или сервер, то это могут быть сотни, или, даже, тысячи дней. И кому тут важна скорость первичного старта ОС?

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

Плюс стандартизация/унификация процессов запуска системы, облегчает жизнь разработчиков сервисов, ибо им не нужно разбираться с нюансами запуска на каком-либо «экзотическом» дистрибутиве…

Ага. И за качеством кода следить не надо: грохнулся сервис, так systemd понимет. Делов-то.

В systemd все эти строчки внесены в систему, написаны на хорошо оттестированном и быстром C, а сервис это просто конфигурация, т.к. по сути они все одинаковые.

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

Я пишу софт, я один раз пишу systemd файлы для него и он работает на любом дистрибутиве. Это в тысячу раз удобней, чем просить пользователя настроить крон

А еще винда есть, раз уж такой разговор

Я пишу софт, я один раз пишу systemd файлы для него и он работает на любом дистрибутиве

Нет. Ибо systemd всё ещё не зохавал мир. :-) И когда от systemd откажутся, твой софт помрёт вместе с ним. Кстати, а как с портированием в ОС, отличные от Linux, у этого софта?

а где ж ваше чувство свободы творить и делать что является основой опенсорц. ??
и то, что патчами можно исключить части системы ?? :) или сделать свое на основе опенсорц-чужого :)

сделать свое на основе опенсорц-чужого

Так сделали уже. GNU Shepard.

https://www.gnu.org/software/shepherd/

В FreeBSD нет systemd, но работает.

Не знал, что мы в треде для домохозяек на сайте для домохозяек

Мир полон чудес, да?

Это до тех пор, пока то, что вы используете в systemd, не прибьют гвоздями к cgroups2. Околодофига софта, который дропнул поддержку не systemd решений, оказался опосредованно завязан на cgroups2. Которые даже не во всяком linux есть.

Потому что Red Hat его не впердолил по самые гланды всем.

Эта шняга где-нибудь кроме GuixSD есть? Потому что Guix – тоже тот ещё раковник.

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

Мде, развиватель. И что же ты, развиватель, пишешь в пускалках? Ах, тебе крона не хватает! Для развития ТВОЕГО приложения! Ну давай, РАЗВЕЙ мысль, что ты там пишешь такого, от ротации, времени луны (и системы) зависящее!

Потому что runit это BSD-init на стероидах, а systemd — полноценный системный менеджер. На системе общего назначения systemd предпочтительней

Эта шняга где-нибудь кроме GuixSD есть? Потому что Guix – тоже тот ещё раковник.

Раковник это Nix в отличии…

С твоими фантазиями нужно гей-порно снимать.

runet, как мне помниться, загружают сервисы ПОСЛЕДОВАТЕЛЬНО

https://smarden.org/runit/benefits

Fast system boot up and shutdown

After the system’s one time tasks (stage 1) are done, the system services are started up in parallel. The operating system’s process scheduler takes care of having the services available as soon as possible.

https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html

Note that the daemon software configured for socket activation with socket units needs to be able to accept sockets from systemd, either via systemd’s native socket passing interface (see sd_listen_fds(3) for details about the precise protocol used and the order in which the file descriptors are passed) or via traditional inetd(8)-style socket passing (i.e. sockets passed in via standard input and output, using StandardInput=socket in the service file).

Внимание, вопрос: где в приведенном примере упоминаются костыли? Или хейтеры, как обычно, несут чушь, не читая документацию?

в FreeRTOS нет этих ваших линуксов и фрибсд, но работает :)

С твоими фантазиями нужно гей-порно снимать.

Уже сняли. Держи: https://lwn.net/Articles/582914/

Эта шняга где-нибудь кроме GuixSD есть? Потому что Guix – тоже тот ещё раковник.

Раковник это Nix в отличии…

Nix отлично работает. А вот с Guix постоянно проблемы.

Плюс, Guix страдает от типичных проблем всех гнутых клонов: чуваки делают новую штуку которая уже как существующая, но ещё БОЛЕЕ ШВАБОДНАЯ, а потом оказывается, что она никому нахрен не всралась. Так было с Hurd, так было с вагоном другого гнутого софта, и вот тут ещё с Guix. По сути ведь основное отличие Guix от Nix даже не в язычке, а в том, что GuixSD не содержит злобной проприетарщины.

...много амбиций...

Пофиксил, не благодари.

В нормальной

Переводится как «у меня лично» или «по моему мнению».

И за качеством кода следить

Ты лично следить будешь?

Ну оно, чувство, при мне) меня ж одного такого умного и красивого на всех не хватает :)