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

Void Linux негодует!

Не знаю что такое runit, но системг распространено по единственной причине - его продвигала шапка.

systemd умеет намного больше, нужно тогда рассматривать runit в связке с другими инструментами. Из того что я прочел, это больше замена daemontools, но не того что открывает диски под Windows.

Если взять именно возможности запустить что то, и управлять этим, то я как простой пользователь ПК не вижу интеграции с cgroups например для отслеживания дерева процессов, создания множественных инстансов одного юнита, и удобных, наглядных команд как systemctl status, настроек юнита таких как перезапуски, таймеров (хотя это уже немного отходит от управления и запуска).

Какие недостатки в ней мешают быть массово используемой?

Нет поддержки RedHat

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

RedHat и его административный ресурс.

Что же получается, т.н. сообщество это не что иное, как мираж?

Долгая история. Если кратко, то Поттеринг относится к наиболее вредному типу людей: те, у кого так себе компетенции, но ОЧЕНЬ много энтузиазма, а RedHat обладает достаточно серьёзным влиянием и ресурсами, что позволило им заразить этой дрянью всех подряд. Даже Дебиан с Арчем не устояли.

С чего вдруг мираж? Сообщество сделало Void, Gentoo, Artix, и даже Devuan. И ещё много чего. Бери да юзай. В чём проблема? Тебе шашечки или ехать? Важно, как дистрибутив устроен, или именно сколько в мире людей, которых ты не знаешь и никогда не встретишь, помимо тебя им пользуются?

Ты бы хоть объяснил, какие у этого рунита достоинства.

У кого программистов на зарплате больше, тот и прав. Редхат скупили себе сообщество в лице команд разработчиков, а затем начали диктовать, что и как.

Работает, свою задачу выполняет. Маленький и лёгкий, код поддаётся полному аудиту одним человеком за один присест. Очень прост в использовании: почти ничего инит-специфического учить не надо, достаточно базовых знаний. Прост в устройсве: если что-то где-то происходит, то легко понять, что и где. В общем, основное достоинство — простота (при полноценном выполнении возложенной задачи).

eudev уже всё. Теперь сборка udev из апстрима, плюс лезут куски еще в виде systemd-utils.

З.Ы. Я так смотрю, сраться веселее - в мою тему за день так никто и не заглянул.

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

Для меня, как для пользователя, systemd тоже работают и прост. Аудит я не провожу.

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

eudev уже всё. Теперь сборка udev из апстрима, плюс лезут куски еще в виде systemd-utils.

Это где? В воиде eudev пока. И basu ещё из имеющего отношение к systemd.

З.Ы. Я так смотрю, сраться веселее - в мою тему за день так никто и не заглянул.

Ну почему не заглянул? Я заглядывал! Понял, что ничем помочь не могу (ибо не использую OpenCV и не обладаю знаниями по нему) и закрыл :)

Википедия пишет:

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

Для меня, как для пользователя, systemd тоже работают и прост.

Пользователь пользователю рознь. Если только браузер запускать и на ЛОР писать, не имея дел с демонами, то можно не вникать. Только это не значит, что systemd прост, это значит, что ты им практически не пользуешься и не знаешь его сложностей. Эдак можно установить скомпиллированную прогу на (ну пусть будет например) хаскелле и говорить, что для тебя как для пользователя хаскел прост, не зная языка даже самую малось.

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

Зачем это делать в руните? «Таймеры» иниту не нужны — это делается в кроне. А ротации вообще обычно реализованы самом логгере, напрмер, в socklog.

Это где?

В Генте. Сослались на трудность сопровождения и поменяли на тот, что в systemd.

Ну ок, как в руните добавить сервис, активируемый по сокету? Тоже не нужно?

когда ошибка в fstab не монтируется только раздел где ошибка сутемд ставит систему раком, дляудалённого администрирования не удобно, мелких и не мелких ошибок нет во встроеном ntp клиенте как в сустемд, место в памяти постоянно не занимет

Ну ок, как в руните добавить сервис, активируемый по сокету?

Да так же, как в любом шелл-скрипте: цикл на три строки.

Тоже не нужно?

Ну вообще это и правда редко нужно. Обычно задача не конкретно по сокету активировать, просто некоторые любят использовать для этого сокет. Например, вместо сокета, сделанного чисто ради активации демона (и да, я видел, что так некоторые делают), зачастую удобнее и проще тупо заюзать тот же incrond.

nofail это слишком сложно, понимаю.

а сервис активируемый по fifo можно?

incrond хочу его без глюков и везде

А что у него за глюки? Сам давно юзаю, глюков не замечал.

runit

# ln -s /etc/sv/<service> /var/service/
# sv up <services>
# sv down <services>
# sv restart <services>
# sv status <services>
# rm /var/service/<service>

systemd

systemctl enable <service>
systemctl start <service>
systemctl stop <service>
systemctl restart <service>
systemctl status <service>
systemctl disable <service>

Молодец! Знаешь!

Сказать-то что хотел?

Таймеры» иниту не нужны — это делается в кроне

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

знаешь

на одном винте sid - на другом void

Сказать-то что хотел?

в чем разница

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

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

Системд же предлагает более менее стандартизированный интерфейс для этой задачи

Он предлашает лишь ещё одну реализацию. Только ещё и такую, которая ещё и с кроном обычно соседствует один хрен.

https://xkcd.com/927/

на одном винте sid - на другом void

Поздравляю. У меня на одном разделе Arch, на другом Void.

А по теме есть что сказать?

Сказать-то что хотел?

в чем разница

Серьёзно? Основная разница в синтаксисе команды запуска и остановки демона? Ну да, это исчерпывающий ответ на вопрос из топика. В остальном ведь они одинаковые…

Серьёзно?

да это все что надо знать домохозяйке

В остальном ведь они одинаковые…

нет конечно - руниты и юниты разные

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

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

которая ещё и с кроном обычно соседствует один хрен

Кстати интересно, надо будет глянуть какие пакеты зависят от крона и зачем

да это все что надо знать домохозяйке

Не знал, что мы в треде для домохозяек на сайте для домохозяек. Спасибо, что сообщил.

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

Так и развивай. Тебе незачем вообще об этом думать.

Кстати интересно, надо будет глянуть какие пакеты зависят от крона и зачем

Мне не встречались. Но мне и те, которые зависят от systemd из-за его таймеров тоже не встречались.

В том, что в нем нет смысла как и в дистрах, которые основаны лишь на идее, что давайте вот заменим systemd на что-то (либо будем ставить rpm через aptitude, а потом объявим себя «отечественным» дистром)

nofail?

systemd умеет намного больше

Только инит бы ему ещё нормальный написать.

Ну в man systemd.socket написано в самом начале:

A unit configuration file whose name ends in «.socket» encodes information about an IPC or network socket or a file system FIFO controlled and supervised by systemd, for socket-based activation.

Должно быть можно. Вроде docker так и работает.

Да так же, как в любом шелл-скрипте: цикл на три строки.

Что за цикл?

Ну вообще это и правда редко нужно. Обычно задача не конкретно по сокету активировать, просто некоторые любят использовать для этого сокет. Например, вместо сокета, сделанного чисто ради активации демона (и да, я видел, что так некоторые делают), зачастую удобнее и проще тупо заюзать тот же incrond.

Не очень понял. Вот конкретно пример с докером. Он активируется по сокету. То бишь после загрузки ОС он не загружен. Но при этом если я выполняю любую команду, то он тут же запускается. Это очень удобно, если он нужен редко. Как это можно циклом на три строчки сделать?

Не очень понял. Вот конкретно пример с докером. Он активируется по сокету. То бишь после загрузки ОС он не загружен. Но при этом если я выполняю любую команду, то он тут же запускается. Это очень удобно, если он нужен редко. Как это можно циклом на три строчки сделать?

Тут ни цикл ни инит не нужны, да и сокет тоже.

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

xinetd

Не нужно городить сложности вокруг простых вещей.

Предложением раньше ты именно это и сделал.

Так это ты сложности предлагаешь городить… Для каждого сервиса писать свои обёртки. Не знаю, что за runit и разбираться лень, но в sysv каждый сервис это несколько десятков, а то и сотен строк башелапши. В systemd все эти строчки внесены в систему, написаны на хорошо оттестированном и быстром C, а сервис это просто конфигурация, т.к. по сути они все одинаковые. И в такой концепции ты один раз реализуешь socket активацию и она работает на все программы в мире, а не предлагаешь для каждой программы писать скрипты-обёртки и прочее.

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

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

Так это ты сложности предлагаешь городить…

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

а сервис это просто конфигурация

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

И в такой концепции ты один раз реализуешь socket активацию и она работает на все программы в мире

Не работает она магически. Её в каждой этой программе ещё заюзать надо. И конфиги понаписать. Точно так же можно реализовать и без сокетов.

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

Да, можно, да, несложно. Это просто разные подходы.

Аминь.

Пример с теми же таймерами. В каждом кроне свои приколы.

Ну так и в systemd с таймерами свои. Только более упоротые.

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

Нет, не работает на любом. Он не работает на том, где нет systemd, или таймер твой не активирован, и т.д.

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

У вас какие-то странные вещи сравниваются. То сам пишешь, то пользователя просить надо. Если оно общее для всех, то это точно так же делается с кроном — пишешь файлик, кладёшь куда надо. Или это делает мейнтейнер дистрибутива. Что они и делают хоть с systemd, хоть с cron — розницы в подходах в этом плане вообще никакой. Если же оно не универсально, и каждому пользователю надо под себя что-то там править — так ему и с systemd это надо будет править.

Нет же. Тут вообще не нужны лишние сущности. Ни соккеты, ни инит, ни цикры. Тупо, блин, выполнить одну команду перед другой — вот и вся задача.
Которая длиннее по объёму, чем скрипт (не для sysv, там правда ужас был), которую при этом сложнее написать и сложнее прочитать.

Почему бы тогда не показать как это делается без systemd? Что бы можно было сравнить для тех кто не видел.

Вот пример на systemd

[Unit]
Description=Foo Service
After=network.target foo.socket
Requires=foo.socket

[Service]
Type=simple
ExecStart=foo-service
TimeoutStopSec=5

[Install]
WantedBy=default.target

[Unit]
Description=Foo Socket
PartOf=foo.service

[Socket]
ListenStream=127.0.0.1:9999

[Install]
WantedBy=sockets.target

Предлагаю показать как это делается без systemd.

Что «это»? Пример с докером делается вообще без инита, тупо скриптом ~/.local/bin/docker (если оно от юзера надо), в котором (псевдокод, я не помню, как там у докера статус и прочее):

#!/bin/sh
docker status || start_docker_command_here
docker "$@"

И всё. Никакие сокеты тут вообще не нужны.

Если нужна именно соккет-активация, то хотелось бы конкретных примеров. Но вообще вот тут для s6 есть подробный ответ, как например можно сделать в том числе: https://skarnet.org/software/s6/socket-activation.html

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

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

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

Я не говорил это про конкретно соккет-активацию. Но по ссылке есть ответ. Мне просто, представь себе, за 25 лет на линуксах, в том числе и с серверами различного назначения, ни разу не требовалась активация именно какого-то демона по сокету, поэтому сейчас из головы сложно взять и выдать пример готовый (для systemd ещё сложнее). Но типа как-то так: until printf "" 2>>/dev/null >>/dev/tcp/foo.socket; do sleep 1; done; foo-service

Ну а более продвинутый вариант есть по ссылке выше для s6. Для runit примерно так же.