Systemd 207

пруфы будут?

http://lwn.net/Articles/520892/

Вообще, приличные демоны:

1. форкаются всегда 2. предоставляют средства управления собой

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

Если этого кода так много, тебе же нетрудно приветсти пример?

не так уж легко, поскольку в федоре уже три или четыре версии, как systemd.

Но вот, например, сервис mediatomb

1) Конфиг сервиса на баше,

2) лежит не в /etc/sysconfig/mediatomb, а в /etc/mediatomb.conf (Это не конфиг демона, как можно подумать, это конфиг именно с переменными для запуска сервиса)

3) В этом конфиге гордо прописано MT_INTERFACE=«not set». При старте сервиса после установке он молча умирает безо всяких разумных сообщений. Я должен через астральный шар найти конфиг, вписать в него в переменную имя интерфейса и тогда будет счастье.

Если не дай боже добавить пробел после равно (MT_INTERFACE = «eth0» ), вся конструкция рухнет...

1. форкаются всегда 2. предоставляют средства управления собой

зачем? Это же плохо, вносить одну и туже функциональность снова и снова. Есть процесс, есть сигналы. Зачем самим себя изолировать и придумывать их заново?

Ага, и еще молиться, что получится дростсточно быстро.

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

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

Но вообще, man 3 daemon. Всё украдено до нас.

Алексей, я согласен с тем, что синтаксические ошибки сильнее бьют по авторам в компилируемых языках. Зато в шелле они отлавливаются легче :)

Но примера именно рэйса я здесь не увидал.

Если у тебя где-то сервер с 500 виртуалок для тонких клиентов, это не значит, что у всех так и никому не нужна скорость перезагрузки.

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

То есть старый добрый способ - повесим баги на ментейнеров - уже не работает и неправильный?

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

скрипты (которые скорее средство автоматизации, чем полноценного программирования) в системе загрузки — это нормально?

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

Значит ты и вправду исходники systemd не видел.

А зачем вменяемому человеку видеть исходники systemd? В этом нет никакой необходимости, потому что сабж just works. В отличие от этих ваших соплей на баше, которые действительно приходится допиливать под каждый чих.

Ну конечно популярной — 9 страниц комментов. :D

Лично тебе оно чем мешает на серверах?

Оно там уже вменяемо работает и документировано? Или вот таким образом надо изгаляться http://www.opennet.ru/opennews/art.shtml?num=37916#272 . А потом что бы разобраться в этом падающем говне нужны будут спецзапросы в рх? И вообще нахуй оно там надо если итак всё работало?

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

О да, блеать. Десять минут и десять секунд на загрузку это невыносимо долго. То ли дело 10 минут.

исправлены некоторые баги; добавлены другие

Зато честно.

А что ты там настраивать собрался? Во-первых, настроено всё уже, во-вторых, там давно уже нечитабельные uuid'ы вместо устройств.

Во-первых, настроено там всё так, как нужно, а не так, как вздумалось вашей убунте. У меня 8 разных разделов, мне их кто должен монтировать, господь бог?

Во-вторых, у невменяемых убунтойдов может там действительно нечитаемые уиды, а у нормальных людей — вполне читаемые имена LVM.

Ну а в-третьих-то нет никакой разницы, прописывать эти параметры в fstab или в unit-файлы systemd. Так что хейтеры и неосиляторы должны страдать. Да.

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

С каких это пор метки LVM стали ненадёжны?

Или вот таким образом надо изгаляться

Как? По ссылке только что-то невнятное без описания проблемы и решения.

Оно там уже вменяемо работает и документировано?

Всегда было. А теперь покажи мне документацию по инитскриптам.

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

Ага, и еще молиться, что получится дростсточно быстро.

да, ведь это сторонний код. Или переписывать, или молиться.

Или, как ты проговорился:

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

Интересно, почему ты адвокатишь подход, который сам же считаешь заведомо ненадежным %)

$почти_весь_код не просто небезопасен с точки зрения запуска в многозадачной системе, а простаки кишит сайдэффектами

Если этого кода так много, тебе же нетрудно приветсти пример?

Но вот, например, сервис mediatomb

И что? Сделано через задницу, но где здесь «небезопасность с точки зрения запуска в многозадачной системе» и каким образом systemd поможет решить проблему?

Как? По ссылке только что-то невнятное без описания проблемы и решения.

А это собственно как писать юниты в твоих любимых системдешечках. С описанием и решением ниже. Хотя если ты diff прочитать не можешь. Ну да «местный злобный тролль» тебе уже объяснил.

Всегда было. А теперь покажи мне документацию по инитскриптам.

Гражданин, не пиздите. Там же было из рассылки, написано самим Поттерингом, Do we have documented that somewhere? Ну тебе то виднее чем архитектору systemd что и где всегда было. По инитскриптам что интересует? Открываешь любой инитскрипт и всё понятно. Практически никого не видел с проблемами понимания скриптов на шеле. Непонятно - открываешь то чем парсятся эти инитскрипты. А любители systemd без гугля фиг что знают. Только сползать в очередное обсуждение и принести оттуда очередное камлание systemd.debug.some.sheet=1

А это собственно как писать юниты в твоих любимых системдешечках.

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

Открываешь любой инитскрипт и всё понятно.

Ага, тонны функций с параметрами типа run-daemon -c 2424 -d «532» -t «abc.pid» -m -p -k. Все так понятно и очевидно, не то что «type=forking» у systemd.

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

Ты по ссылке читал? Гражданин Шигорин пытался сделать юнит с определённым поведением. Правда юнит совершенно нелогично должен выглядеть для такого поведения.

Ага, тонны функций с параметрами типа run-daemon -c 2424 -d «532» -t «abc.pid» -m -p -k.

Что за бред? Зайди в /etc/init.d и найди такую ахинею в скриптах.

Зайди в /etc/init.d и найди такую ахинею в скриптах.

start-stop-daemon --start --quiet --pidfile \
                    /var/run/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS || true

Инит-скрипт для nginx: 96 строк. Юнит для nginx: 14 строк. Работают одинаково. Еще вопросы?

Конечно есть вопросы. Где вот эта херня " -c 2424 -d «532» -t «abc.pid» -m -p -k" это во первых. Во торых - тут уже спрашивали где nginx.conf, где make_dirs(), где configtest()?

Во торых - тут уже спрашивали где nginx.conf, где make_dirs(), где configtest()?

Откуда я знаю? Я вижу скрипт и вижу, что он работает. Этот юнит писал не я, и как он берет конфиги я не знаю.

Где вот эта херня " -c 2424 -d «532» -t «abc.pid» -m -p -k" это во первых.

Вот:

--start --quiet --pidfile \
                    /var/run/$NAME.pid --exec $DAEMON --DAEMON_OPTS

Откуда я знаю? Я вижу скрипт и вижу, что он работает. Этот юнит писал не я, и как он берет конфиги я не знаю.

Отлично. То есть он не работает так же как инитскриптовый. И ты не знаешь как он именно работает. Но ведь полностью уверен в идентичности. Насчёт работает - обратно на опеннет.

Вот:

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

То есть он не работает так же как инитскриптовый.

С чего ты взял? Может там в сам systemd заложено доставание конфига из одноименного файла в conf.d

Но ведь полностью уверен в идентичности.

Потому что параметры подхватываются одинаково, демоны работают одинаково.

С чего ты взял? Может там в сам systemd заложено доставание конфига из одноименного файла в conf.d

То есть ты сам не знаешь? Ухаха. Документированный ты наш.

Потому что параметры подхватываются одинаково, демоны работают одинаково.

Что, прям все разные демоны работают одинаково? Только названиями отличаются?

С чего ты взял? Может там в сам systemd заложено доставание конфига из одноименного файла в conf.d

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

Потому что параметры подхватываются одинаково, демоны работают одинаково.

Да ну? И где там тестирование конфига в юните? А где создание директорий? Без разница как там работают демоны. Тобой гарантировался идентичный функционал инитскрипта и юнита. Пока доказательств этого нет. Но ты можешь начать куски с-кода тащить из системд. И показать что получившийся юнит идентичен исходному скрипту по возможностям.

То есть ты сам не знаешь?

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

Тобой гарантировался идентичный функционал инитскрипта и юнита.

С чего ты взял?!

Пока доказательств этого нет.

Как и доказательств обратного.

С чего ты взял?!

Вот это кто писал:

Инит-скрипт для nginx: 96 строк. Юнит для nginx: 14 строк. Работают одинаково.

Одинаковость работы инитскрипта и юнита означают идентичность их работы.

Как и доказательств обратного.

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

Одинаковость работы инитскрипта и юнита означают идентичность их работы.

Да. Данных конкретных скриптов. Я нигде не говорил, что абсолютно все гипотетические скрипты работают одинаково, и уж тем более ничего не гарантировал.

Да. Данных конкретных скриптов. Я нигде не говорил, что абсолютно все гипотетические скрипты работают одинаково, и уж тем более ничего не гарантировал.

О юлить начал. Здесь уже был скрипт и юнит nginx. Про эти совершенно конкретные вещи мы и говорили а не гипотетические. Поэтому я ещё жду доказательств идентичности.

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

Ясно. Как точно работает системд ты не знаешь. Про отличную документацию ты только слышал. Разобраться в задачке на написания юнита для выполнения определённого действия не осилил. Не сумел доказать что ускорение на сервачках загрузки на 10 секунд очень значимо, когда загрузка идёт 10 минут. Идентичный инитскрипту юнит ты не смог предоставить. Судя по всему ты даже не понимаешь как работает инитскрипт, если выдаёшь «пробовать все возможные варианты конфига, чтобы проверить их идентичность». Я ничего не забыл?

Пилять, тебе самому не стрёмно от собственного убожества? Или ты им здесь упиваешься?

Хоть я ничего и не имею против systemd на десктопе, но люто удваиваю этого анонима. Задрали тупые невежды, такие как vurdalak, пытающиеся выставить свои абсолютные нули в качестве какого-то там «мнения». Пять звёзд, ёпта. Плоть от плоти ЛОРа.

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

Код — это реализация алгоритма, решающего задачу. В данных примерах логика задачи требует формализации грамматики и соответствующего парсера.

Граматика у утилит разработанных разными разработчиками? Может в какой-либо яблочной конторе такое и возможно но свободные системы - нет.

Никакая логика не требует процедуру длиной в 1200 строк с 30+ точками выхода; хардкод строковых литералов - это, в общем-то, довольно коряво. То есть даже кодер из поццеринга хреновый.

Ну так прошу. Покажи эту же логику без 1200 строк с такой же обработкой ошибок. И насчет строковых литералов. Ты бы вынес литерал в константу что бы потом использовать эту константу в одном месте? Так кто тут быдлокодер после этого?

Покажи эту же логику без 1200 строк с такой же обработкой ошибок.

Переписать эту функцию? $500.

И насчет строковых литералов.

Эти строковые литералы определяют внешний интерфейс программы.

Ты бы вынес литерал в константу

Да. И написал бы doc-комментарий.

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

Анон, у тебя с чтением кода проблемы? Там все константы повторяются как минимум два раза - в определениях данных и в теле обработчика сообщений. Ну а сколько раз повторяется «org.freedesktop.systemd1.Manager», мне даже считать лень.

Так кто тут быдлокодер после этого?

Тот, кто этого не делает. Ты бы не сделал? Значит, ты.

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

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

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

Пять звёзд, ёпта. Плоть от плоти ЛОРа.

Вообще-то 5 звёзд означает, что человек очень любит почесать языком.

P.S. Хочется верить, что количество звёзд не коррелирует с одной очень известной пословицей...

Да. И написал бы doc-комментарий.

Скопировал бы ман по вызываемой утилите? Флаг в руки.

Анон, у тебя с чтением кода проблемы? Там все константы повторяются как минимум два раза - в определениях данных и в теле обработчика сообщений. Ну а сколько раз повторяется «org.freedesktop.systemd1.Manager», мне даже считать лень.

Ну найди мне повторение LoadUnit. А константу ты бы назвал org_freedesktop_systemd1_Manager1? Что бы было говорящее название... Если как ты работают программистами, то мне грустно за будщее этой отрасли в России... Или ты не из России? Ну тогда пох.

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

http://www.freedesktop.org/software/systemd/man/systemd.slice.html

http://www.freedesktop.org/software/systemd/man/systemd.cgroup.html

Нет, это можно реализовать на баше (желающих, впрочем, не видел), но я не хочу представлять, КАК это отлаживать и КАК это будет тормозить.

Уверен, что не умеет? Конкретно это я не смотрел, но сомневаюсь, что такой фичи там нет.

Скопировал бы ман по вызываемой утилите?

Сгенерировал бы документацию.

Ну найди мне повторение LoadUnit.

Да не вопрос: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3... и http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3...

Если как ты работают программистами, то мне грустно за будщее этой отрасли в России...

Тебе и без этого есть о чем грустить.

Сгенерировал бы документацию.

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

Круто, нечего сказать.

Да не вопрос: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3... и http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c?id=3...

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

как будто данные федоропроблемы это проблемы классического инита?

Разорвать описывающую интерфейс строку на сотню маленьких

Во-первых, она уже разорвана; во-вторых, ты просил показать тебе повторение «LoadUnit» - я показал, в чем проблема?

А правильное решение тебе уже назвал baka-kun - парсер языка.

Вот после таких как ты и бросают поддержку программ

Ты ее не бросал, анон - тебя уволили за лень и профнепригодность.