не нужен

уже было?

Попробуй запихать туда JobTimeoutSec

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675175

А, мейнтейнер, похоже, в сомнениях и не хочет тратить время на systemd в данный момент.

Попробуй запихать туда JobTimeoutSec

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

Processes will first be terminated via SIGTERM (unless the signal to send is changed via KillSignal=). If then after a delay (configured via the TimeoutSec= option) processes still remain, the termination request is repeated with the SIGKILL signal (unless this is disabled via the SendSIGKILL= option). See kill(2) for more information.

Кстати да, скорее лучше использовать TimeoutSec, а не JobTimeoutSec. А то это таймаут вместе с зависимостями выйдет, после которой транзакция будет отменена >_<

TimeoutStopSec по дефолту выкручен в 90 секунд. Так что пара-тройка косых служб, и 5 минут набежит

Жесть-жестянка. Мне одно интересно: каким образом все эти службы прекрасно работали с initscripts, и почему внезапно окосели именно при переходе на systemd?

Просто там никто не парился, выключилось ли оно действительно, или нет

Пункты 1 и 2 уже выполнены

еще нет. вот когда будет явная зависимость от либ системд - тогда да.

Удав вроде форкнули как раз в первую очередь

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

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

ты тоже в зог веруешь?

Просто там никто не парился, выключилось ли оно действительно, или нет

ИЧСХ, всё прекрасно работало. Так это, что, выходит, баги в демонах, которые не умеют нормально останавливаться, потому что рассчитывают, что их тупо прибьёт инит?

Жаргон простого быдла прямо.

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

Жесть-жестянка. Мне одно интересно: каким образом все эти службы прекрасно работали с initscripts, и почему внезапно окосели именно при переходе на systemd?

...
        # Kill it.
        if [ -n "$pid" ] ; then
                [ "$BOOTUP" = "verbose" -a -z "${LSB:-}" ] && echo -n "$base "
        if [ -z "$killlevel" ] ; then
               if checkpid $pid 2>&1; then
               # TERM first, then KILL if not dead
               kill -TERM $pid >/dev/null 2>&1
               usleep 100000
               if checkpid $pid && sleep 1 &&
                  checkpid $pid && sleep $delay &&
                  checkpid $pid ; then
                                kill -KILL $pid >/dev/null 2>&1
                usleep 100000
               fi
                fi
            checkpid $pid

...

SL5, классический инит

А никто не думал на Кикстартере замутить сбор средств на ликвидацию Поттеринга? Мне кажется, набралось бы средств достаточно.

eudev вроде как не сдох. Можно написать разработчикам, что мол, пилите форк.

С чего бы вдруг?

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

лично я держу себе локальный форк для своих нужд.

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

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

Долго смеялся. Вы опять берете свои игрушки начала 21 века и считаете что в то время когда пилили sysv init можно было сделать ваш полный аналог юнитов. Да там системд на 99% юниксов запустить нельзя было, так как у этих юниксов было 16 КИЛОБАЙТ оперативной памяти. Вот и приходилось писать то, что только «при коммунизме» станет системд. То есть сейчас вот, когда «коммунизм» настал, ага - вот мы sysv init и переписываем. То есть да, systemd это sysv init при «коммунизме» :D

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

И вот так же жутко ваш ситсемд выглядит, просто вы этого не понимаете.

Это верно. Впрочем, у этой гибкости есть побочный эффект - зная что нужно поменять, сделать это в автоматическом режиме практически нереально. Как пользователю awesome, мне этот факт хорошо известен.
Развитие инитов двигалось к вырождению этой фичи.

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

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

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

В openrc, например, наблюдается практически полное вырождение DSL в более узкий DSL. В бебиане похожая история. Если посмотреть на предлагаемый skel инита, то в большинстве случаев заполняться будет только шапка.

И какой вывод мы из этого делаем?

Причем тут еще важно понимать, что именно захардкожено в системде.
Это движек зависимостей в первую очередь,

Вы понимаете что сейчас вы в очередной раз аргументировали позицию «системд - монолитное говно» :D

Движок зависимостей это именно движок - я с вами абсолютно согласен. Более того, он *идеально* юниксвеется. То есть висит отдельным процессом которому кормят зависимости, а потом посылкой команд выясняют что нужно. И легко может быть в правильном виде использоваться в *любой* системе инициализации.

Это по сути идеально ложится даже в пункт юниксвея «делайте фильтром» - этот движок фильтр и есть. Более того, этот движок может быть компилятором. Мы ему забросили все зависимости - он нам сгенерил (например)байткод что и при каких событиях делать. Более того, если правильно разработать этот миниязык описания зависимостей, то например было бы удобно часть событий «скомпилировать» а часть оставить вариативной. И результирующая фигня влезет в какие нибудь десятки килобайт и ее смогут использовать и в самом эмбедном эмбеде.

А можно на «десктопах» один раз компилять зависимости и пока не поставили нового пакета или не поправили конфиги - они не изменились. И целая куча Си кода не может подвесить всю систему - движок зависимостей просто не запускается :D

машина управления состоянием, интерфейсы к дубасу итд.

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

Например в опенрц движок зависимостей также реализован на С.
Аналогов стейтфулл системы на миниязыках нет - это просто не рационально.

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

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

Собственно юнит в [Service] секции - это просто как аргументы для start-stop-daemon, а в [Unit] — грубо говоря как depend{} секция в openrc или LSB заголовок в SysV. Я не считаю что это плохо.

Это плодит неудобства - удобнее как LSB заголовок. А еще удобнее завести кроме start|stop в скрипте еще команду depend например. И если она есть - читать зависимости оттуда.

То есть это я к чему - все что делает systemd можно делать вот без этих ужасов. Но вы там не только не хотите этого понимать, но еще и упорно настаиваете на том что предложенное решение лучшее и что resistance is futile :D

творения ЛП просто работают

Продолжай верить и почаще повторяй эту фразу.

Долго смеялся. Вы опять берете свои игрушки начала 21 века и считаете что в то время когда пилили sysv init можно было сделать ваш полный аналог юнитов.

Я ничего не считаю. Я указываю на то, что говорить, что inittab - полный аналог юнитов — некорректно.

И вот так же жутко ваш ситсемд выглядит, просто вы этого не понимаете.

Я понимаю аргументы против, и не все из них нахожу заслуживающими внимания.

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

При крупных изменениях в апстриме придется синхронизировать метод инциализации вручную. Например, переименуют сервис, и оп-ля. Или параметры запуска поменяются.

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

Ну вот и оптимизировали

И какой вывод мы из этого делаем?

Что отдельный миниязык для системы инициализации не нужен. Достаточно всунуть костыли там, где они необходимы. А там где они не необходимы - не всовывать.

Вы понимаете что сейчас вы в очередной раз аргументировали позицию «системд - монолитное говно» :D

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

Движок зависимостей это именно движок - я с вами абсолютно согласен. Более того, он *идеально* юниксвеется. То есть висит отдельным процессом которому кормят зависимости, а потом посылкой команд выясняют что нужно. И легко может быть в правильном виде использоваться в *любой* системе инициализации.

Согласен, если бы это так написали, это было бы мило. Маловероятно, что кто-то бы этим пользовался, но, тем не менее.

Это по сути идеально ложится даже в пункт юниксвея «делайте фильтром» - этот движок фильтр и есть.

Фильтр в юниксвее это про пайпы. Движок не может быть однонаправленным. Так что это не про то. Вообще у нас уже есть движек зависимостей один, make называется. Его даже кто-то использовал для этого )))

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

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

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

Похоже на аргументы свидетелей иеговы

Это плодит неудобства - удобнее как LSB заголовок.

Чем удобнее

А еще удобнее завести кроме start|stop в скрипте еще команду depend например. И если она есть - читать зависимости оттуда.

Это было бы мило, наверное. Только зачем?

То есть это я к чему - все что делает systemd можно делать вот без этих ужасов. Но вы там не только не хотите этого понимать, но еще и упорно настаиваете на том что предложенное решение лучшее и что resistance is futile :D

Я поверю в это, когда увижу работающий PoC

Стараюсь соответствовать сабжу.

eudev вроде как не сдох. Можно написать разработчикам, что мол, пилите форк.

после акта закармливания поттеринга конфетами - считай, что мертв.

и не собираюсь. но только по причине лени

Я поверю в это, когда увижу работающий PoC

пруф чего? возможности чесать правое ухо левой ногой через спину? сделать это можно. но нужно ли?

сделать это можно. но нужно ли?

Я не знаю. Как по мне - и так все ок

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

То есть, ты прочитал все треды про systemd и ничего не понял? Совсем ничего?

и интерфейса к DBus - это как-то слишком дофига.

Сам dbus тоже монструозен. И, кстати, почему не слышно криков что он монолитен и написан чёрт-знает-как?

Он не пишет сообщений на консоль при загрузке ))

Сам dbus тоже монструозен.

И вкомпилирован статически?

Сам dbus тоже монструозен. И, кстати, почему не слышно криков что он монолитен и написан чёрт-знает-как?

Потому что не так уж много софта прибито к нему гвоздями?

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

systemd теперь умеет симпатично выводить информацию на консоль о подвисших задачах

Теперь винде/sbin/init точно капец!

если появится - сам буду использовать. только сомнуха давит. а braindamaged, весьма годный форк, из-за eudev сдох

и судя по коммитам в https://github.com/gentoo/eudev - что-то очень кисло

К сожалению, это незаконно, кикстартер такое не разрешит.

Не всё в этом мире идеально, но это не значит, что к нему не нужно стремиться.

Не все но срачи видел. Почему сутемд хуже не понял. ну вот совсем.

Почему сутемд хуже не понял. ну вот совсем.

Ну не судьба, значит.

Ну щяс под опенрц посижу и скажу.

Я видел что последний коммит месяц назад.

Разработчики сказали, мол мы не видем цели. Погоди, когда удав окончательно сольется с говноd, будет уже поздно. Придется всем жрать systemd.

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

Я ничего не считаю. Я указываю на то, что говорить, что inittab - полный аналог юнитов — некорректно.

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

При крупных изменениях в апстриме придется синхронизировать метод инциализации вручную. Например, переименуют сервис, и оп-ля. Или параметры запуска поменяются.

А этого в принципе никак не избежать. Просто не надо к проблемам неизбежным добавлять проблемы избегаемые.

Ну вот и оптимизировали

Создав 4меговый бинарь требующий полного Си тулчейна для изменения этого бинарного конфига? Нюню. Отличная оптимизация КОНФИГА, бро :D

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

Скажите это Поттерингу и самому себе.

Достаточно всунуть костыли там, где они необходимы. А там где они не необходимы - не всовывать.

По этому мы сунули очень простой вариант этого языка: ini файлы с огромным числом «переменных». Так как эти переменные влияют еще и на flow of execution - у нас как раз таки отдельный миниязык для системы инициализации. Но ужасно кривой и завязанный конкретную версию си блоба.

Вы понимаете что сейчас вы в очередной раз аргументировали позицию «системд - монолитное говно» :D

У меня нет с этим проблем, в любом случае.

Окей. То есть это таки монолитное говно. Вот еще один фанат системд сознался. А как дышали, как дышали - постили ссылки на разоблачения мифов :D

Я использую монолитный монолитный системде на монолитном линаксе.

Вообще то линукс как раз модульный просто до упора - по сравнению с системд. Команда modprobe и объем того что вынесено в модули это наглядно демонстрирует. :D

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

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

Фильтр в юниксвее это про пайпы. Движок не может быть однонаправленным. Так что это не про то.

Вот так и рождаются нездоровые сенсации. Сейчас опять выяснится что вы критикуете юниксвей потому что даже пайпы воспринимаете ... альтернативно.

Скажите что такое по вашему программа в пайпе, типа sort например? Что вам мешает посылать команды на вход пайпа, а ответы на команды читать с выхода пайпа? :D

Вообще у нас уже есть движек зависимостей один, make называется. Его даже кто-то использовал для этого )))

make не удобен в режиме работы в качестве «демона».

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

Прямо сейчас понятно что нужно не адаптеры делать - потому что в апстрим не примут, а смотреть что можно отрезать от системд.

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

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

Похоже на аргументы свидетелей иеговы

Чем именно? Вы действительно этой вот простой вещи не понимаете - что просто наваять огромный глючный си-блоб гораздо проще любого юниксвея?

Это плодит неудобства - удобнее как LSB заголовок.

Чем удобнее

Тем что все описание поведения процесса, вместе с костылями - в одном месте.

А еще удобнее завести кроме start|stop в скрипте еще команду depend например. И если она есть - читать зависимости оттуда.

Это было бы мило, наверное. Только зачем?

Это дает гибкость - мы можем перевычислять зависимости согласно любому доступному нам в скрипте методу. Ну и что бы можно было взять тонны уже готовых init скриптов для «непопулярного» софта(под который безумные фанаты системд ваять юниты не будут - так как «ненужно, и энтерпрайз ненужен») и сопряч их с depend-based системами инициализации. При этом у нас получается гибкость скриптов - возможность делать любую политику через вот этот предоставленный механизм.

Я поверю в это, когда увижу работающий PoC

Я думаю учитывая то какая степень срача стоит - ждать осталось не так долго.

Весь праздник испортил. Впрочем, как всегда.

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

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

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

да нет. sysvinit - многоярусная система, в отличие от systemd. и некорректно сравнивать только inittab или только rc.d или только init.d с юнитами. сравнение должно быть комплексным

ЩИТО

Перечитай, подумай, покури, еще раз перечитай. Если есть возражения - приводи факты.

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

Мне действительно стоит описать фундаментальные отличия, и почему этим никто не мог пользоваться?

А этого в принципе никак не избежать. Просто не надо к проблемам неизбежным добавлять проблемы избегаемые.

Ну, вообще то, выделив именно конфигурацию, избегается большинство проблем. В генте с openrc я никогда не обновлял conf.d и всегда неглядя init.d.

Создав 4меговый бинарь требующий полного Си тулчейна для изменения этого бинарного конфига? Нюню. Отличная оптимизация КОНФИГА, бро :D

КОНФИГ там текстовый, бро.

Скажите это Поттерингу и самому себе.

Поттерингу это говорить не нужно, он и так сделал так как сделал.

Так как эти переменные влияют еще и на flow of execution - у нас как раз таки отдельный миниязык для системы инициализации. Но ужасно кривой и завязанный конкретную версию си блоба.

Переменные вообще очень часто влияют на flow of execution, иначе зачем они нужны?

Окей. То есть это таки монолитное говно. Вот еще один фанат системд сознался. А как дышали, как дышали - постили ссылки на разоблачения мифов :D

Я пользуюсь линаксом, фаерфоксом и емаксом. У меня понятие монолита отлично от монолитофобов. От называний чего-либо монолитом суть не меняется

фанат системд

Спасибо, поржал

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

Это.. фильтр?!1

make не удобен в режиме работы в качестве «демона».

Но его же можно упаковать в баш с while :; do, и сгружать туда события по дубасу с dbus-monitor. Или это уже по твоему ненужные усложнения? ))

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

БО^W UNIX-WAY ДЕЛАЕТ НАМ СТРАДАТЬ ПОТОМУ ЧТО ЖЕЛАЕТ НАМ ДОБРА! :D

Отлично. Лучших, а значит дорогих решений не будет, потому что они лучшие и дорогие. Ну, не будет значит не будет. Будем о них мечтать, значит. Помолимся, бро? ))

Тем что все описание поведения процесса, вместе с костылями - в одном месте.

Поведение, которое «конфигурируется» LSB заголовком, находится _совсем_ в _другом_ месте.

Я думаю учитывая то какая степень срача стоит - ждать осталось не так долго.

Поживем - увидим

Получается если лопата веками выполняла свою работу хорошо, то мотоблоки нам какбы теперь и ненужны? Имхо у systemd есть шанс со временем превратиться в мотоблок против лопаты. А это прогресс, развитие и всё такое

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

и скажу.

Право, не сто́ит.

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