Райса также вдохновила статья Ауринна Шоу о так называемой «культуре презрения». По словам Шоу, люди проявляют презрение (например, к разработчикам, которые используют другой язык программирования) в качестве социального знака, способа показать, что они принадлежат к правильной группе.
Безусловно, в этой истории есть такая культура: большие группы сообща проявляют общее презрения к systemd и к тем, кто использует эту систему. Отсюда вытекает концепция изменения или сопротивления. Да, знакомые вещи удобны. Но они не обязательно хороши, особенно если ничего не меняется уже много лет.
Истоки трагедии
По словам Райса, происхождение systemd связано с корнями самой системы Unix, которая была «счастливой случайностью» — реакцией на внешнюю сложность прежних систем. Unix был кардинально упрощён во всех отношениях, включая загрузку пользовательского пространства. Подсистема
init заведовала всем «хозяйством», включая монтирование файловых систем и запуск демонов. Хотя это совершенно разные задачи, но их объединили в один процесс.В те дни важных демонов было мало:
cron, update (чья работа заключалась в том, чтобы иногда выписывать суперблоки файловой системы), и сам процесс init. К моменту выхода 4BSD у Unix и появился правильный демон getty, сетевые демоны вроде routed и telnetd, а также «супердемон» inetd. Именно здесь ситуация начала становиться интересной, но некоторое время всё это работало достаточно хорошо.А потом случился Интернет. Хотя
inetd нормально справлялся с небольшими объёмами трафика, но не мог создавать новый процесс на каждое входящее соединение. Тем временем веб-сайты обзавелись базами данных и другими системами с сохранением состояния между соединениями. Представление о демоне сместилось в сторону «сервиса», а это совсем другой зверь. Старый init мог только запустить сервис, но после этого становился практически бесполезен.Частично проблема заключалась в объединении сервисов и конфигурации. Такие задачи, как монтирование файловых систем, относятся к последней разновидности; они обычно выполняются один раз во время загрузки, после чего забываются. Но такого подхода недостаточно для автоматизированного управления сервисами, которое требует постоянного внимания. Вот так на свет появились сервис-ориентированные системы, такие как Upstart и systemd. Здесь Unix пошла по пути, проторенному другими ОС. По словам Райса, у Windows NT с самого начала была сильная сервисная модель, а у Mac OS она до сих пор работает в виде
launchd. Другим системам приходилось догонять.Apple выпустила
launchd в версии Tiger, где он заменил целую серию демонов обработки событий, включая init, cron и inetd. Таким образом, systemd стал попыткой позаимствовать хорошие идеи, реализованные в launchd. Когда Леннарт Пёттеринг начал решать эту проблему, он сначала посмотрел в сторону Upstart — системы, основанной на событиях. Она ещё работала на скриптах, но Пёттеринг пришёл к выводу, что сможет сделать лучше. В своей статье Rethinking PID 1 он называет launchd одним из образцов для работы. Он думал о повышении скорости загрузки и необходимости настройки системы инициализации на аппаратные и программные изменения в работающей системе. Во время создания init системы были статичными, но современная среда гораздо динамичнее, чем тогда.Сервисный уровень
Классические Unix-подобные системы делятся на два основных компонента: ядро и пользовательское пространство. Но ядра со временем стали более динамичными и изменчивыми, подстраиваясь под оборудование, на котором они работают. Это привело к необходимости создания нового «сервисного слоя» (service layer) между ядром и пользовательским пространством. Этот слой включает в себя компоненты вроде
udev и Network Manager, но systemd стремится обеспечить комплексный сервисный уровень; именно поэтому со временем он вбирал в себя функциональность таких компонентов как udev. Процесс шёл довольно успешно и был принят большинством (но не всеми) дистрибутивами Linux, хотя часто сопровождался язвительностью со стороны сообщества.Против демона systemd часто звучат одни и те же аргументы: например, что он нарушает философию Unix. Райс предполагает, что этот аргумент основан на понятии, что systemd представляет собой единый монолитный двоичный файл. На самом деле systemd структурирован иначе: это много отдельных двоичных файлов, поддерживаемых в рамках одного проекта. Как «человек BSD» (он входил в число основных разработчиков FreeBSD), Райс находит смысл в таком объединении смежных концепций. Systemd — вовсе не раздутая и монолитная система, как считают некоторые критики.
Говорят, что в systemd много багов. «Это же софт», конечно, в нём будут баги, сказал Райс. Представление о том, что в отличие от любой другой системы systemd должен быть совершенным, поднимает планку слишком высоко. По крайней мере, у systemd практически всегда разумный режим работы при отказе, сказал он.
В той или иной форме часто повторяется одна жалоба, которую можно сформулировать так: «Не выношу Леннарта Пёттеринга». Райс отказался защищать стиль общения Пёттеринга, но сказал, что нельзя не восхититься силой воли и решимостью Пёттеринга. Не каждый сможет пройти через всё это.
Systemd не стремится к портируемости на системы, отличные от Linux, что приводит к отдельному классу жалоб. Если systemd станет стандартом, существует риск того, что операционные системы за пределами Linux станут ещё более изолированными. Многие хотят, чтобы systemd придерживался стандартных для Unix интерфейсов, но у Райса для них простой ответ: «Unix мёртв». Когда-то Unix был упражнением в предельной переносимости и имел реальный успех. Но теперь мы живём «в мире Linux с небольшими ошибками округления» (что человеку от FreeBSD больно говорить), и нет смысла придерживаться классических интерфейсов Unix. Нынешняя ситуация является «патологической монокультурой», где Linux может диктовать условия.
Systemd много выиграл в такой ситуации. Например, контрольные группы — высокоэффективный и интересный механизм управления процессами, без них было бы гораздо труднее решать эти задачи. Они гораздо более мощные и детальные, чем джейлы FreeBSD. Разработчики систем типа FreeBSD могут видеть угрозу в непереносимости systemd. Но эта ситуация также даёт им возможность свободно работать и искать собственные решения этих проблем.
Перемены и трагедия
Райс говорит, что миссия systemd сводится к большим разрушительным изменениям — вот где начинается трагедия. У нас нердов сложное отношение к изменениям. Да, это потрясающе, когда мы сами их создаём, но изменениям нельзя доверять, если они приходят извне. Systemd представляет тот вид внешне навязанных изменений, который люди находят угрожающим. Люди противятся таким изменениям даже от приятных разработчиков, не говоря уже о Пёттеринге, который не особо сочувствует окружающим. Это приводит к рефлекторным реакциям. Но людям нужно отступить и подумать, что они делают. «Никто не должен угрожать Леннарту смертью из-за какого-то программного обеспечения», — говорит Райс. Презрение — это не круто.
Вместо этого стоит подумать: почему вообще появился systemd и почему это важно? Какую проблему он решает? Для критиков одним из решением может быть попытка создать собственную альтернативу: они поймут, насколько весёлая эта задача. Кроме всего прочего, эта история показывает разницу в мышлении у нового поколения, которое рассуждает о системах больше с точки зрения API и контейнеров, например.
Итак, какие выводы можно сделать из истории systemd? Один из выводов: нельзя недооценивать транспорт сообщений. Systemd интенсивно использует шину D-Bus, которая во многом обеспечивает его гибкость. Райс не сторонник D-Bus, но большой сторонник шин для обмена сообщениями между процессами. В своё время он лоббировал создание такой нативной шины в BSD-системах, желательно встроенной в ядро и с лучшей безопасностью, чем у D-Bus. Поверх неё можно сделать надлежащую систему удалённого вызова процедур, где компоненты ядра и пользовательское пространство будут работать на одном уровне. В правильно спроектированной системе процесс просто отправит запрос API, не беспокоясь о том, где и как этот запрос будет обработан.
Среди прочих уроков — важность поддержки надлежащего жизненного цикла службы без необходимости установки дополнительных систем управления службами. Важно наладить автоматизацию обслуживания через API; и systemd обеспечивает многое из этого. Поддержка контейнеров также важна: это полезный способ инкапсуляции приложений.
Итак, в современных Linux-системах systemd выполняет роль сервисного слоя. Это хорошая платформа для управления службами, но она не должна быть единственной альтернативой. В systemd есть ряд полезных функций, включая удобные пользовательские юниты, последовательное именование устройств и даже хорошую модель журналирования, сказал Райс. Двоичные журналы — неплохая вещь, пока у вас есть инструменты, чтобы вытащить оттуда информацию. И systemd предоставляет новую модель приложения. Вместо одного двоичного файла приложение становится кучей модулей в одном контейнере.
Мир вокруг нас меняется, сказал Райс. Мы можем либо отдаться течению, либо сопротивляться ему. В первом случае, вероятно, плыть будет проще, чем во втором. Райс предложил всем, кто критикует systemd, более пристально изучить эту систему и попытался найти в ней хорошие вещи. Возможно, тогда завершится фаза катарсиса нашей трагедии — и мы сможем двигаться дальше.
Видеозапись выступления опубликована на YouTube.
Комментарии (273)
a0fs
04.02.2019 00:57Например, контрольные группы — высокоэффективный и интересный механизм управления процессами, без них было бы гораздо труднее решать эти задачи. Они гораздо более мощные и детальные, чем джейлы FreeBSD.
Странно разработчику FreeBSD сравнивать CGroups c jail. Насколько я знаю CGroups — это метод управления разделением ресурсов системы между группами процессов. С Jail скорее соотносятся пространства имён. Да и чрезмерная навороченность cgoups не позволяет ими пользоваться в отрыве от такого инструмента как systemd, поскольку управлять руками всеми этими параметрами нереально (а реально ли ими вообще управлять человеку? это всё помещается в одну голову?). В FreeBSD можно пользоваться учётом и ограничением ресурсов, причём вешать это ограничение именно на jail-ы объединяя группы процессов в контейнеры, что ИМХО намного прозрачнее управлением ресурсами по-сервисно.
у Райса для них простой ответ: «Unix мёртв». Когда-то Unix был упражнением в предельной переносимости и имел реальный успех. Но теперь мы живём «в мире Linux с небольшими ошибками округления»
Когда-то это мир принадлежал Microsoft Windows, и эти времена ещё не прошли до конца. Кроме того в самом Unix были лидеры отрасли, захватывающие поляну на время. ИМХО не стоит настолько ультимативно заявлять о безальтернативности Linux…
gecube
04.02.2019 01:07ИМХО не стоит настолько ультимативно заявлять о безальтернативности Linux…
мир очень изменяется. Раньше были и мейнфреймы, к которым одновременно подключались сотни пользователей. А завтра — все вычисления будут в облаке, поверх lambda / FaaS. И эти линуксы будут никому не нужны. Точнее не так — они будут обеспечивать работу всей этой махины, только знать их нужно будет именно тому персоналу, который обеспечивает этот промежуточный слой. А потребителю услуги (т.е. разработчику) будет предоставлена возможность писать код на более высоком уровне абстракции на его любимом языке.
keydon2
04.02.2019 02:25+1Чур вас с облаками.
Они нужны для крайне малой категории задач и пускай там и остаются, в большинстве случаев они противопоказаны. Вычисления, если возможно, нужно производить ближе к пользователю.
Мощностей пользовательского оборудования сейчас более чем достаточно, особенно если избавиться от ненужных абстракций "любимого" языка программирования. Если пропускную способность с горем попалам поднимают(и далеко не бесплатно), то задержки сети и доступность ещё никому победить не удалось, не говоря уже о потери контроля за данными.gecube
04.02.2019 06:36Есть идея о будущем буме «пограничных вычислений», но что-то я пока ни оборудования не вижу, ни технологий для этого. Может просто плохо смотрел, т.к. это пересекается с основной деятельностью чуть менее чем никак.
Kubernetes поверх «малинок» уже возможен и на одном из митапы его продавали. Но этого недостаточно, чтобы эту область вытянуть.a0fs
04.02.2019 22:07Kubernetes поверх «малинок» уже возможен и на одном из митапы его продавали.
А применение этому безобразию то какое? ну кроме отказоустойчивых микросервисов управления домом…gecube
04.02.2019 22:26ну, типа надежные пограничные вычисления + уже известный фреймворк и методики управления (ну, там манифесты и пр.).
Что-то такого плана www.youtube.com/watch?v=1vTn9qs24Ug
a0fs
04.02.2019 22:12Раньше были и мейнфреймы, к которым одновременно подключались сотни пользователей. А завтра — все вычисления будут в облаке, поверх lambda / FaaS
Ну то есть ничего не поменялось, кроме интерфейса доступа к Mainframe. Ведь если вычесть из стоимости этой железки всё ЧСВ её создателей и продвигателей на выходе останется решение с достаточно оптимальным соотношением отказоустойчивости, управляемости, энергопотребления… Проблема то этих машин только в запретительной цене закупки и поддержки.
norguhtar
04.02.2019 10:57cgroups позволяет создавать контейнеры. Собственно doker поверх них и бежит.
mxms
04.02.2019 00:59+3Вот эта попытка менять весь мир под себя (есть мейнстримный Linux, а все остальные идут лесом) очень напоминает то, как себя вёл Microsoft cо своим Windows в своё время. В итоге игнорирование, или, в более мягкой формулировке — недостаточное внимание, ко мнению общественности пошло самому продукту во вред.
Собственно тот же процесс начался и на Linux, когда вследствие такого рода эгоцентричности страдать начинают сами пользователи системы. К примеру, чего стоит недавнее заявление о том что ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится.
divanikus
04.02.2019 01:36В смысле не включат или в смысле что даже dkms не соберешь?
UPD: Для ленивых — www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Workaroundmxms
04.02.2019 11:48Не знаю, что там у вас не будет собираться, потому что у меня всё собирается много лет начиная с FreeBSD 8.0 прямо с ядром.
Насчёт перспектив в Linux лучше почитать предыдущий тред вместе с комментариями.
https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Problemdivanikus
06.02.2019 13:34DKMS — Dynamic Kernel Module Support. Механизм для сборки и подключения модулей ядра не из основной ветки. И да, даже DKMS сломается, потому что из ядра выкинуть часть необходимых API(?).
begemoth3663
04.02.2019 12:57+1К примеру, чего стоит недавнее заявление о том что ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится.
Просто обратите внимание на общую [для всего мира] тенденцию — не нужно потребителю знать, что там под капотом: закройте глаза и пользуйте. Сломалось — несите в СЕРВИС. Вот и в ИТ Вам будут продавать сервис: *aaS
Смириться. Пока тенденцию не качнёт обратно :)
P.S. потому на *tree-fs и строят всякие "лисапеты", вместо того, чтобы просто сделать zfs diff :))
Stanislavvv
04.02.2019 17:15-1Проблема в том, что zfs при поломках значительно сложней чинить… Под линуксом zfs всё ж менее надёжна, чем тупая и не самая быстрая ext4, но которая в 99% случаев даже не потребует fsck при ребуте кнопкой.
Под фрей поломать zfs мне не удавалось, а вот под линуксом на не слишком интенсивном i/o, но зато на требовательных по памяти задачах — получил oom с kernel panic и потерю данных в разделе с zfs. Ну и, к тому же, отдавать до четверти памяти под рабочие структуры фс — иногда перебор, тут всё ж не сервер-хранилище, а запускалка приложений в виртуалке с единственным /dev/vda.
pal666
04.02.2019 20:16Сломалось — несите в СЕРВИС.
P.S. потому на *tree-fs и строят всякие «лисапеты», вместо того, чтобы просто сделать zfs diff
а какими глазами на вас посмотрит сервис, когда вы придете к нему со сломанным зфс диффом?
pal666
04.02.2019 20:24ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится
зол никогда не была и никогда не будет энтерпрайз реди. просто потому что энтерпрайз не совместим с неподдерживаемым tainted ядром. в то же время есть энтерпрайз дистры, в которых дефолтная файловая система бтрфс. которая ими поддерживается и у которой, в отличие от зфс(даже солярисовой, которая таки да энтерпрайз, а не неподдерживаемый костыль), не устаревший дизайнmxms
04.02.2019 23:16зол никогда не была и никогда не будет энтерпрайз реди
Очень может быть что так. Однако, и альтернатив реальных пока нет.
BTRFS по многочисленным отзывам даже её поклонников, а также отказу от поддержки её развития со стороны "пингвинячьего всего" Redhat, находится на расстоянии лет (если не вечности) от стадии enterptise ready. Только на Oracle и надежда.
Несмотря на более современную архитектуру.pal666
05.02.2019 07:44из редхата просто все разработчики бтрфс поуходили в фейсбук, там ее некому поддерживать. т.е. это сложности редхата, а не бтрфс. в сусе разработчики есть, бтрфс поддерживается в слес, так что в полный рост энтерпрайз.
suhr
04.02.2019 01:05+4Как и ожидалось, в статье нет ни слова про daemontools, runit или Supervisor, но вместо этого — ложная дихотомия sysvinit vs systemd, и попытки преподнести любую критику как простое ретроградство.
Поклонники systemd, однако, такие поклонники.
gecube
04.02.2019 01:10Ну, так сделайте нормальное сравнение. Докажите свою точку зрения. И возможно, что Вы убедите, например, меня, что OpenRC или runit — это правильно.
suhr
04.02.2019 01:52У меня нет намерения что-то доказывать (сам использую систему с systemd и не страдаю). Просто было бы неплохо излагать историю объективно, а не как в политике.
pal666
04.02.2019 20:37+1Как и ожидалось, в статье нет ни слова про daemontools, runit или Supervisor, но вместо этого — ложная дихотомия sysvinit vs systemd
это легко объяснимо. раньше везде стоял сис5инит, теперь везде стоит системд, т.е. произошла массовая миграция с одного на другой. автор описывает этот процесс. с демонтулс на ранит никто не переходил и никакой трагедии не происходило, т.е. описывать нечего.
Поклонники systemd, однако, такие поклонники.
автор слегка разработчик фрибсд. видимо, его купили
Scf
04.02.2019 01:05+2то, что systemd сложнее, чем init.d — это его недостаток, а не преимущество.
gecube
04.02.2019 01:09-2Сложность в чем? Мы же прекрасно понимаем, что можно делать простые системы, которые потом обрастают дополнительными модулями и костылями, т.е. становятся сложными в эксплуатации, если юзкейсы выходят за рамки минимального функционала. Так и наоборот — существуют сложные системы, которые просты в эксплуатации. Это относится и к systemd, kubernetes и прочим новомодным штукам. Другой вопрос, что эти сложные системы иногда ломаются и тогда нужно уметь спускаться на нижние слои абстракции, чтобы уметь их чинить, но это нужно далеко не всегда )
norguhtar
04.02.2019 11:03Он проще. Да сам по себе как софт systemd сложнее. Но вот с точки зрения всей инфраструктуры он проще. И проще он за счет большей сложности systemd. Достаточно хоть раз написать systemd unit и скрипт инициализации под один из дистрибутивов linux.
powerman
04.02.2019 16:40-4run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
gecube
04.02.2019 16:41Скорее да, чем нет. Но можно ли в них удобно настраивать те же cgroups?
Вопрос для личного образования, а не чтобы потроллить.powerman
04.02.2019 16:45-1Нельзя. По фичам daemontools и runit сильно отстают от systemd, в s6 фич намного больше и он старается внедрить многое из systemd но с правильной архитектурой, но поддержки cgroups нет и в s6, насколько я помню. Зато мы получаем cgroups из коробки в docker, и, как по мне, этого более чем достаточно — никогда не понимал зачем нужны cgroups для традиционных системных сервисов (ну т.е. приятно, когда они есть из коробки, спору нет, но вот реальной пользы я от них для системных сервисов ни разу не видел и не слышал о таком).
gecube
04.02.2019 16:51ну т.е. приятно, когда они есть из коробки, спору нет, но вот реальной пользы я от них для системных сервисов ни разу не видел и не слышал о таком
я приводил кейс и могу повторить. Мы хотим распилить один большой мощный сервер на несколько задач, чтобы они не подрались за ОЗУ, за процессор, и при этом не хотим активировать своп (на сервере — mongodb, clickhouse, маленький postgres для метрик и куча http rest api).powerman
04.02.2019 17:19-1Я говорил про пользу для системных сервисов (syslog, ssh, vpn, dhcp, cron, dns, smtp, etc.). Всё остальное, нужное именно нашему проекту, запускается в докере, и там cgroups и лимиты есть.
gecube
04.02.2019 17:38+1Я допускаю, что в этом случае достаточно CoreOS Container Linux в качестве хостовой системы. И не нужно никаких daemontools и runit…
norguhtar
04.02.2019 19:18Вообще в таком случае лучше пилить таки по контейнерам. Но лучше по нормальным, а не по docker. Банально проще администрировать.
pal666
04.02.2019 20:46+2никогда не понимал зачем нужны cgroups для традиционных системных сервисов
это от нежелания ознакомиться с документацией по системд. они нужны например для того, чтобы можно было надежно остановить сервис, у которого форкаются процессыpowerman
04.02.2019 21:08-2Можно узнать, какие из стандартных системных сервисов ведут себя таким образом? Не форкают вспомогательные процессы — таких хватает, а оставляют их после себя получив SIGTERM?
Кстати говоря, cgroups для решения этой проблемы обычно не требуется, если сервис работает под выделенным системным аккаунтом то можно убить все процессы этого юзера через
pkill -u USER, но обычно достаточно убить группу процессов (все нормальные сервисы обычно вызываютsetsid(2)) черезkill -PID. Если же сервис запускается под root, не сделал setsid сам, наплодил процессы которые сделали собственный setsid, да ещё и не реализовал подчистку запущенных процессов при получении SIGTERM — может не надо таким системным сервисом вообще пользоваться?
Всё это и есть типичнейший пример подхода systemd "do more" вместо "do less", при котором дополнительным усложнением героически решается теоретическая проблема, которая на практике вообще не существует.
pal666
05.02.2019 07:56+1можно убить все процессы этого юзера через pkill -u USER
нельзя, если они могут форкаться в это время, pkill не atomic
может не надо таким системным сервисом вообще пользоваться?
может не надо пользоваться супервизором процессов, который работает только если никто не делает резких движений?
pal666
05.02.2019 11:21+2может не надо таким системным сервисом вообще пользоваться?
среди системных сервисов вы по собственной инициативе перечислили cron. а крон что делает? он форкает пользовательские задачи. любые. которые могут форкать все, что им взбредет в голову
norguhtar
04.02.2019 19:17Да ладно? Можно пример? Вот простейший пример для unit
[Unit]
Description=Test service
[Service]
Type=simple
ExecStart=/usr/bin/blalbla
ExecStop=/bin/kill -s SIGINT $MAINPID
[Install]
WantedBy=default.target
Это самый простой вариант.powerman
04.02.2019 19:47-1А вот практически то же самое для daemontools/runit/s6, файл
./runв каталоге сервиса:
#!/bin/sh exec /usr/bin/blalbla 2>&1
Отличие в том, что при остановке сервиса убивать его будут через SIGTERM, а не SIGINT (вообще, SIGINT для сервисов, серьёзно???). В случае runit есть возможность изменить SIGTERM на SIGINT создав второй файл
./control/t:
#!/bin/sh sv i .norguhtar
04.02.2019 19:49+2Ага только вот проблема. Что там у вас за sh? А от этого может сильно зависеть как будет отрабатывать ваш скрипт. Причем более того в дистрибутивах то они разные, что уж за другие юниксы говорить.
Выключать можно 100500 разными методами. Это пример из моего ближайшего шаблона, там надо такой посылать чтоб сервис убирал за собой сокет.powerman
04.02.2019 19:54У меня скрипты эти написаны на POSIX sh, отработает гарантированно на любой реализации /bin/sh любого дистрибутива. В ./run-файлах практически никогда не встречается сложной логики, а-ля скрипты init.d — там в 99% банально редиректы STDERR и exec в нужный сервис с нужными этому сервису аргументами командной строки. Иногда цепочка вспомогательных утилит делающих exec друг в друга для задания ограничений сервису, напр.:
#!/bin/sh exec 2>&1 exec envuidgid tinydns envdir ./env softlimit -d400000 /usr/bin/tinydns
Это всё абсолютно портабельно, повода для паники нет.
norguhtar
04.02.2019 19:58Даже в ubuntu? Даже в том случае если в место sh используется zsh? Проблема в том что там будет с /bin/sh заранее узнать нельзя да и вообще не должна такая утилита привязываться к shell хоть какому-то.
powerman
04.02.2019 20:16Ещё раз. Медленно. Есть стандарт. POSIX-совместимые sh. Все используемые варианты шелла, которые можно обнаружить в качестве /bin/sh в любых дистрибутивах *NIX — являются POSIX-совместимыми. И этот стандарт поддерживает довольно много всего, так что вполне можно писать достаточно сложные sh-скрипты, которые будут работать везде (разве что кроме винды, да и то, сейчас и это уже не так очевидно).
Кстати, есть вспомогательные утилиты вроде checkbashisms, которые могут подсказать если случайно в скрипте использовали фичу не входящую в POSIX sh.
norguhtar
04.02.2019 20:35Все используемые варианты шелла, которые можно обнаружить в качестве /bin/sh в любых дистрибутивах *NIX — являются POSIX-совместимыми.
csh к примеру не является совместимым.
Дополнительно могут различаться пути расположение самих пакетов и т.п. Как итог сделать универсальный запускатель во всех возможных дистрибутивах может быть затруднительно, даже с systemd. Дополнительно напомню все дружно кладут на использование только POSIX-совместимых инструкций shell. Кучу раз эти грабли собирал уже.
Так что с портабельностью ровно те же проблемы что и sysvinit и многих других.
Я в свое время смотрел кучу разных init систем. Из нормальных которые реально удобно пользоваться и дают все необходимое ровно две это openrc и systemd. И да у openrc при этом свой отдельный обработчик сценариев как и systemd. Это позволяет не зависеть от того какой там shell стоит в конкретной системе и дополнительно ограничивает художества которые делают некоторые люди.powerman
04.02.2019 20:52-1Можете назвать хоть один дистрибутив, в котором csh/tcsh запускается как /bin/sh?
Пути расположения действительно отличаются (потому что предложенный DJB /package так и не стал популярным), но какое это имеет отношение к данной дискуссии? Разве в unit-файле ExecStart работает как-то иначе?
norguhtar
04.02.2019 20:56+1Можете назвать хоть один дистрибутив, в котором csh/tcsh запускается как /bin/sh?
Админ может поменять. Внезапно ага.
Разве в unit-файле ExecStart работает как-то иначе?
В systemd можно прописать PATH и не указывать пути при запуске к примеру. Причем глобально это можно сделать.
Насчет же дискуссии могу сказать, что в большинстве случаев администраторы банально не обладают должной квалификацией. По этой причине unit в systemd позволяет не отстрелить ногу с ходу вполне приличная штука.powerman
04.02.2019 21:12Админ может поменять. Внезапно ага.
Не может — у него пол системы ляжет. А вообще он может сделать rm -rf /bin — и что, надо быть к этому готовым и иметь запасной набор бинарников в /var/tmp/резервный-bin/?
В systemd можно прописать PATH и не указывать пути при запуске к примеру. Причем глобально это можно сделать.
Не может быть! В обычных sh-скриптах тоже так можно! Ну надо же, как здорово, что в POSIX sh додумались включить такую продвинутую и уникальную фичу systemd.
norguhtar
04.02.2019 21:13В каждый скрипт прописывать будете?
powerman
04.02.2019 21:27Вы издеваетесь? Всегда есть место, куда можно прописать глобальное значение PATH по умолчанию. Например при использовании runit для запуска сервисов его обычно задают непосредственно перед запуском runsvdir — команды, которая запускает все сервисы, примерно так:
#!/bin/sh PATH=/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin exec env - PATH=$PATH runsvdir -P /etc/service
В этом случае все ./run-файлы будут видеть именно это значение PATH и никаких других переменных окружения по умолчанию у них не будет.
norguhtar
04.02.2019 21:33+4И опять мы дружно делаем еще один sh скрипт. Да кстати еще один дополнительный момент, для настройки всего этого хозяйства требуется редактировать sh файл со всеми вытекающими. К примеру можно довольно легко сломать запуск. И это не шутка :)
pal666
04.02.2019 21:28Разве в unit-файле ExecStart работает как-то иначе?
если «иначе» это «не зависит от /bin/sh», то да. чтобы запустить шелл из юнитфайла, надо запускать =/bin/sh ...., ну или =/bin/script.sh…
я не думаю, что кто-то использует csh вместо шелла, но есть много других вариантов с разной степенью корявости. если вы протестировали свой скрипт в системе х, где /bin/sh это bash, он совсем необязательно будет работать в системе у, где это ashpowerman
04.02.2019 21:43"иначе" — это "не зависит от $PATH"
Скрипт будет работать везде, если писать его без башизмов и контролировать это тулзой вроде checkbashisms.
pal666
04.02.2019 23:32+2ExecStart= само по себе не использует $PATH, первое слово это полный путь к программе.
вы регулярно приводите примеры скриптов, которые не будут работать на моей системе (т.к. запускают бинари, которых у меня нет), несмотря на отсутствие башизмов.powerman
04.02.2019 23:39-1Может это Вас шокирует, но Вы делаете ровно то же самое — приводите примеры unit-файлов, которые не будут работать на моей системе (т.к. для их выполнения нужен не установленный у меня systemd).
И если Вы нажмёте на кнопочку "Показать ветку комментариев", то убедитесь, что я привожу эти примеры не потому, что утверждаю что они запустятся на Вашей системе, а в подтверждение моего утверждения в начале ветки:
run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
pal666
05.02.2019 00:04+2системд идет в стандартной поставке мейнстрим дистров. если у вас лфс, то вы сами за себя и не ожидайте, что кто-то будет напрягаться
И если Вы нажмёте на кнопочку «Показать ветку комментариев», то убедитесь, что я привожу эти примеры не потому, что утверждаю что они запустятся на Вашей системе, а в подтверждение моего утверждения в начале ветки:
run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
у вас не выходит подтвердить это утверждение. получается только «нигде не работающие скрипты в простейшем случае ровно такой же сложности, как юнитфайл, но лишены всех его плюшек»powerman
05.02.2019 00:10У меня Gentoo. Плюс из популярных без systemd есть ещё как минимум Devuan, Arch и Slackware. А вообще список достаточно большой: http://without-systemd.org/wiki/index.php/Linux_distributions_without_systemd
gecube
05.02.2019 08:19+1Про Arch не надо. Это как минимум не соответствует действительно, иначе зачем арчеводы сделали страничку — wiki.archlinux.org/index.php/Systemd_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)
По-вашему, это благотворительность? Т.е. они пишут статьи для пользователей других дистрибутивов?
Давайте сойдемся на том, что есть дефолтная конфигурация дистрибутива и кастомная.
Насчет Slackware вообще не в курсе — его еще не похоронили?
Т.е. реально из Вашего списка только Devuan строго не systemd-дистриб.
sn00p
05.02.2019 00:08+2Проще. Но есть нюансы.
Как предлагаете делать systemd-analyze critical-chain, например?
Если я, например в userspace что-то разрабатываю, как мне сделать такое? Startup finished in 1.297s (kernel) + 2.825s (initrd) + 8.695s (userspace) = 12.818spowerman
05.02.2019 00:22-2Вы не поверите, но у меня за всю загрузку системы отвечает ровно один sh-скрипт размером 200-300 строк. Пример этого скрипта Вы можете найти в статье Как загружается Linux в разделе "Startup: /etc/runit/1".
Так что при желании измерить этот "userspace" можно тупо вписать несколько строк
dateмежду любыми этапами загрузки (они все в виде вызовов функций перечислены в конце скрипта). И, будем откровенны, насколько часто и насколько большому количеству разработчиков нужно замерять это время — и стоит ли их удобство в эти моменты установки systemd, со всеми его уязвимостями и "особенностями", большинству обычных юзеров?sn00p
05.02.2019 00:32+1Так у вас там в первых двух строках прекрасное и можно дальше уже не читать.
Всё в одном файле — при обновлении приложений практически невозможно автоматически обновить код инициализации этого приложения. Например, когда обновляется ALSA, то пакет может просто заменить файлы /etc/init.d/alsasound, /etc/conf.d/alsasound, /etc/modules.d/alsa. А в моём случае админу нужно будет ручками править /etc/runit/1.
Нет поддержки всего на свете
Ну и сколько вы эти шашечки рисовали? А если надо будет поставить вдруг pulseaudio? Шашечки хорошо, но когда ехать-то?
Если я захочу заняться разработкой под андроид, например?
Что мне работодателю сказать, извини, дружок, через три месяца начнем, мне тут надо все запустить сначала?
Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают. Я правильно понял? Этим занимаются все нормальные разработчики и всегда. По полгода пилят софт, чтобы полсекунды выйграть.powerman
05.02.2019 00:49-1Шашечки рисовал некоторое время. Это был интересный проект для саморазвития и изучения процессов, которые происходят при загрузке системы. Так что время не жалко.
Но любопытный факт в том, что на поддержку этого у меня за 15 лет ушло до смешного мало времени, хотя за это время много чего изменилось. При этом эти скрипты за 15 лет использовались на некотором количестве десктопов и серверов, причём не только мной. В общем, это только выглядит страшно, а на практике работает весьма неплохо.
При этом надо отметить, что в случае каких-то проблем при загрузке этот подход позволяет найти и исправить проблему практически моментально, потому что весь выполняющийся при загрузке код максимально краткий, простой и очевидный — при этом отладка аналогичных проблем в sysvinit, OpenRC и systemd требует намного больше времени и усилий, потому что там задействовано намного больше кода, файлов, конфигов, а в случае systemd ещё и сложных и местами глючных (или скажем политкоректнее "с не всегда очевидным поведением") инструментов.
Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают.
Нет, я спрашивал о профилировании кода, выполняющегося при загрузке системы. Что касается профилирования обычных прикладных приложений/сервисов — я не понимаю, какое вообще отношение к их профилированию может иметь systemd, для этого существуют намного более практичные штатные инструменты.
sn00p
05.02.2019 00:59+3Например, какие такие штатные инструменты позволяют оценить, сколько твоя программа отожрала при загрузке времени, в целом и в интеграции с другими сервисами?
300 строк — это максимально краткий, простой и очевидный код? А по пять строк юниты — это код сложный и запутанный, ну акей. Пока вы саморазвиваетесь в интересных проектах, люди деньги хотят зарабатывать. Если сравнить это с такси, никому ваше такси не будет интересно, если вы приедете через месяц после заказа, с криками, смотрите какие я тут шашечки нарисовал. Для себя ок, прикольно, не спорю, хотя есть и поприятнее занятия, как по мне. Но какой в этом business value?powerman
05.02.2019 01:42-1Например, какие такие штатные инструменты позволяют оценить, сколько твоя программа отожрала при загрузке времени, в целом и в интеграции с другими сервисами?
Для анализа работы сервисов специально придумали логи и метрики — моя программа обычно выводит такую информацию в них.
Сколько времени мой сервис запускается в условиях когда одновременно запускаются вообще все сервисы — мне обычно не интересно, частично потому что такое случается только при редких перезагрузках серверов (а сервисы обычно обновляются/перезапускаются по одному), и частично потому что этой информацией сложно воспользоваться для чего-то полезного (она не покажет какой сервис нуждается в оптимизации). Но если вдруг мне это станет интересно — время затраченное на полную перезагрузку сервера и запуск всех сервисов легко увидеть на тех же метриках.
К слову говоря все данные systemd относятся к текущему серверу, а современные сервисы гораздо чаще всё-равно разворачиваются на кластерах, и статистику хочется смотреть по всему кластеру, а не по отдельному серверу — и для этого метрики намного удобнее systemd.
300 строк — это максимально краткий, простой и очевидный код? А по пять строк юниты — это код сложный и запутанный, ну акей.
300 строк на sh у меня делают то, что делает значительная часть кода самого systemd плюс значительная часть unit-файлов, которые systemd выполняет при загрузке системы (исключая те unit-файлы, которые запускают обычные сервисы вроде ssh/vpn/etc. — аналог этих unit-файлов у меня в ./run-файлах, тоже которые занимают меньше строк).
В общем, Ваша цитата это очередная попытка сравнивать тёплое с мягким, довольно типичная для любителей systemd — хотя никак не могу понять, почему это настолько распространённая проблема…
Но какой в этом business value?
Я получил простую и очень надёжно работающую систему, требующую минимум времени на поддержку. С успехом использую её 15 лет, на своём десктопе и десктопах нескольких друзей, плюс на серверах кучи проектов в которых я участвовал до появление докера (с докером что стоит на хосте стало намного менее принципиально), и пока что не вижу причин от неё отказываться — все известные мне альтернативы работают менее надёжно и/или требуют больше усилий на поддержку, а их основные достоинства в том, что они более популярны и/или поддерживают не нужные лично мне фичи. Так что business value в том, что я за 15 лет сэкономил кучу времени и нервов.
sn00p
05.02.2019 08:53У вас в разных комментариях взаимоисключающие утверждения.
Я получил простую и очень надёжно работающую систему, требующую минимум времени на поддержку
Что может быть минимальнее, чем
dnf upgrade
, например.
А вот тут вообще песня.
Да, в списке процессов болтаются всякие самозапустившиеся «сервисы» вроде /usr/libexec/gvfs-udisks2-volume-monitor, /usr/libexec/udisks2/udisksd, gpg-agent, /usr/libexec/dconf-service etc. без нормального runit-супервизора. Это немного раздражает, но без веских причин, скорее просто по принципу «потому что тишина должна быть в библиотеке!». По факту у них просто собственный жизненный цикл, кто-то их автоматом запустил когда они понадобились, и если они крешнутся, то этот кто-то их и перезапустит когда они снова понадобятся.
Ну да ладно. Вас уже не в ту степь понесло.
Какие-то метрики уже появились. Причем тут метрики и
процесс загрузки системы?
pal666
05.02.2019 00:37+1у меня за всю загрузку системы отвечает ровно один sh-скрипт
т.е. ваша система не живет в динамичном мире, в котором живут все остальные. в реальном мире набор запущенных сервисов не определяется жестко одним скриптом, а реагирует динамически на меняющиеся внешние условияpowerman
05.02.2019 00:51Этот скрипт не запускает никаких сервисов, он отвечает за необходимую инициализацию системы перед тем, как runit параллельно запустит все сервисы. Сами сервисы запускаются практически однострочными ./run-файлами, как Вы видели в примерах, и никакой проблемы в процессе работы запускать новые сервисы или останавливать/удалять/перезапускать/обновлять работающие нет.
pal666
05.02.2019 01:26+1значит, этот скрипт не сможет вам сказать «Startup finished in 1.297s (kernel) + 2.825s (initrd) + 8.695s (userspace) = 12.818s», потому что в userspace входит запуск всех сервисов параллельно
pal666
04.02.2019 21:12+1Иногда цепочка вспомогательных утилит делающих exec друг в друга для задания ограничений сервису, напр.:
#!/bin/sh
exec 2>&1
exec envuidgid tinydns envdir ./env softlimit -d400000 /usr/bin/tinydns
а покажите цепочку, которая настраивает несколько приватных маунтов, мне такое часто надо
ну и кстати, /bin/sh не делает ваш скрипт посикс совместимым, в моей посикс совместимой системе нет ни envuidgid, ни envdir. в этом и польза стандартизации системд
Это всё абсолютно портабельно
см выше. по сравнению с системд это все абсолютно непортабельноpowerman
04.02.2019 21:19-1У меня этот run-файл не менялся с начала 2000-х, когда я ещё использовал daemontools. Сейчас использую runit, а с ним в комплекте идёт утилита chpst, которая умеет делать всё то же самое, что и этот конвейер. Иными словами, если пишется ./run-файл для runit, то в нём гарантированно можно использовать chpst для этих целей, а если он пишется для daemontools — то можно использовать вышеупомянутые утилиты.
Что касается совместимости с POSIX sh, то она не требует ограничиваться в sh-скрипте исключительно командами включёнными в POSIX, иначе вообще практически ни один скрипт не может считаться совместимым.
Приватные маунты это прекрасно, но речь идёт о системных сервисах — кому из них нужны приватные маунты? А не системные сервисы запускаются в докере, где приватные маунты доступны.
pal666
04.02.2019 21:37+3Иными словами, если пишется ./run-файл для runit, то в нём гарантированно можно использовать chpst для этих целей, а если он пишется для daemontools — то можно использовать вышеупомянутые утилиты.
а если пишется юнитфайл, то в нем гарантировано можно использовать синтаксис юнитфайлов. и это будет работать на любом мейнстрим дистре, в отличие от ранита и демонтулс
Что касается совместимости с POSIX sh, то она не требует ограничиваться в sh-скрипте исключительно командами включёнными в POSIX, иначе вообще практически ни один скрипт не может считаться совместимым.
почему? посикс описывает набор утилит. все остальное — это зависимость не на посикс, а на что-то другое.
Приватные маунты это прекрасно, но речь идёт о системных сервисах — кому из них нужны приватные маунты?
всем нужны, чтобы не видеть лишнего. но я строчку попросил не для системных сервисов(т.к. это умеет системд), мне и в простых скриптах надо
pal666
04.02.2019 20:57А вот практически то же самое для daemontools/runit/s6, файл ./run в каталоге сервиса:
ну т.е. совсем не то же самое. чтобы убивать через сигтерм, в оригинальном примере достаточно удалить строку, он по дефолту так убьет. а не по дефолту (как в примере) делается одной простой строкой. но это не все отличия. в примере юнитфайла есть описание, в вашем примере никакого описания нет(нет, строка комментария не подойдет, описание из юнитфайла доступно программно для запущенных сервисов). в примере юнитфайла указано, куда этот сервис встраивается в дерево зависимостей, в вашем примере этого нет. и сделать это одной строкой нельзя. в примере юнитфайла автоматически работает огромное количество дефолтных плюшек, которых в вашем примере нет, потому что вы не слышали о пользе cgroups и т.д.
#!/bin/sh
exec /usr/bin/blalbla 2>&1
Отличие в том, что при остановке сервиса убивать его будут через SIGTERM, а не SIGINTpowerman
04.02.2019 21:40-1чтобы убивать через сигтерм, в оригинальном примере достаточно удалить строку, он по дефолту так убьет
В моём примере достаточно удалить файл
./control/tи он тоже по дефолту убьёт через SIGTERM — и, честно скажу, файл всегда удалить проще, чем строку.
а не по дефолту (как в примере) делается одной простой строкой.
А не по дефолту делается одним простым файлом из, по сути одной строки (если не считать #!/bin/sh).
в примере юнитфайла есть описание, в вашем примере никакого описания нет(нет, строка комментария не подойдет, описание из юнитфайла доступно програмно для запущенных сервисов)
Это правда, но лично мне всегда хватало имени сервиса чтобы с ним работать, можно узнать почему Вам его недостаточно и как в этой ситуации помогает длинное описание?
в примере юнитфайла указано, куда этот сервис встраивается в дерево зависимостей, в вашем примере этого нет
А это потому, что ни в daemontools ни в runit нет зависимостей. И, Вы не поверите, но они там нафиг не нужны — если какому-то сервису при старте не хватило какой-то зависимости (поскольку он случайно запустился раньше неё), то он тупо пишет в лог "ой", падает, и runit через секунду его перезапускает, что полностью решает проблему. В s6 зависимости есть, но на практике их отсутствие в runit никогда не создавало проблем, так что переходить ради зависимостей на s6 я пока не вижу смысла.
и сделать это одной строкой нельзя.
Вообще-то в s6 зависимость указывается именно одной строкой.
в примере юнитфайла автоматически работает огромное количество дефолтных плюшек, которых в вашем примере нет, потому что вы не слышали о пользе cgroups и т.д.
Я прекрасно знаю о пользе cgroups, просто я не вижу реальной пользы от cgroups на практике для системных сервисов — а все остальные, для которых польза безусловно есть, я запускаю в докере.
pal666
04.02.2019 22:33честно скажу, файл всегда удалить проще, чем строку.
вы не с той стороны заходите. я имел в виду, что по дефолту этой строки нет, а если хочется, то можно добавить строку. что проще, чем добавить файл(нет, это делает не админ в командной строке, а разработчик сервиса в редакторе)
делается одним простым файлом из, по сути одной строки (если не считать #!/bin/sh).
вам дали избыточный пример, который дает повод для критики непосвященным. в юнитфайле можно точно так же из одной строки(если не считать [Service]):
[Service]
ExecStart=/usr/bin/blalbla
я посчитал, это одинаковое количество символов с вашим скриптом. только тут на самом деле огромное количество фич включено по дефолту
как в этой ситуации помогает длинное описание?
понятнее вывод systemctl list-units? но, как мы уже выяснили, если вам не надо описание, вы его можете не писать. а если надо, то вам поможет только юнитфайл
И, Вы не поверите, но они там нафиг не нужны
не поверю, потому что я знаю, зачем они нужны. если, к примеру, у вас есть сервис, которому нужна база данных, то в системд он явно указывает зависимость. если вы не будете запускать сервис(а с сокет активейшн это превращается в «не будете пытаться коннектиться клиентом), то и базу данных никто запускать не будет(в отсутствие других клиентов базы данных). а как только понадобится запустить сервис, он стартанет и базу данных. все устаревшие альтернативы(включая апстарт с ивентами) вынуждены в такой ситуации просто сходу стартовать все, что в принципе установлено в систему, даже если оно может понадобиться только в следующее полнолуние, а может и не понадобиться вовсе
Вообще-то в s6 зависимость указывается именно одной строкой.
как это помогает раниту и демонтулс?
я не вижу реальной пользы от cgroups на практике для системных сервисов
хттпд — системный сервис? полезно ли на практике точно прибить его вместе со всеми форкающимися цги? „я не вижу пользы“ не всегда свидетельствует об отсутствии пользы, иногда это отсутствие знаний и вообще это странный аргумент против чего-то, в чем все остальные пользу видятpowerman
04.02.2019 22:55-1хттпд — системный сервис?
Нет. Системные — те, которые нужны для обслуживания системы, а не прикладных задач юзера вроде веб-сайта компании: acpid, agetty, atd, cups, cron, dhcpd, dns, syslog, mcelog, vpn, smtp, ssh, ну и docker.
в чем все остальные пользу видят
Ну так расскажите, какие конкретно реальные проблемы с любыми из вышеупомянутых сервисов помогут решить cgroups?
pal666
04.02.2019 23:23+1почему перечисленный список сервисов чем-то важнее других(особенно, в контексте убивания сервиса)? откуда уверенность, что никто из этого списка не использует форк?
я уже несколько раз повторил: есть надежный способ убить все процесссы в сигруппе, нет надежного способа убить произвольное дерево процессов, которые в этот момент могут форкатьсяpowerman
04.02.2019 23:34-1Окей, повторю основную мысль ещё раз: systemd делает много ненужного, решает не существующие на практике проблемы, и за всё это приходится платить очень высокую цену (включая уязвимости в настолько критичной части системы).
Дальше идёт разбор конкретных фич, например cgroups, и мы пытаемся определить нужные они или нет. Вы утверждаете, что это крайне нужные и полезные фичи. Я утверждаю, что если использовать сервер определённым образом (запуская все наши прикладные сервисы вроде http и DB) в докере, то пользы от cgroups в systemd нет, поскольку под управлением systemd остаются только системные сервисы (вроде перечисленных мной выше), у которых тупо нет проблем, которые надо решать через cgroups. При этом я нисколько не спорю с полезностью cgroups, просто в моём случае я получаю управление cgroups через docker, а не systemd.
pal666
04.02.2019 23:54+2основная мысль состоит в том, что системд делает много нужного и решает существующие на практике проблемы, именно поэтому специально обученные люди, занимающиеся сервисами в мейнстрим дистрибутивах, перешли на него.
громкая критика системд слышна только от дилетантов, которые плохо разбираются и в сервисах в целом и в системд в частности.
кстати, раз уж он не в первый раз всплывает, рокет — сила, докер — могила.
и это, давно докер стал портабельным за пределы линуха(основной аргумент против сигрупп)?
и про уязвимостиpowerman
05.02.2019 00:03-1Да, уязвимости докера меня лично сильно беспокоят. Но тут такое дело, по факту выбор ведь не между docker и systemd, а между systemd+docker или runit+docker — и второй вариант очевидно содержит намного меньше уязвимостей.
Что касается k8s и прочих альтернатив докеру — не имею ничего против, в контексте данной дискуссии абсолютно всё-равно какой инструмент используется для управления контейнерами и cgroups для контейнеров, вопрос в том есть ли какая-то реальная польза для cgroups для системных сервисов, или нет.
pal666
05.02.2019 00:09+2в системд есть встроенная поддержка неймспейсов. плюс с ним идет systemd-nspawn, так что докер необязателен. и вопрос исключения сигрупп ради портабельности никак не обработан
sn00p
05.02.2019 00:16+2Для embedded, иногда даже для серверов еще можно оправдать легковесные разного рода супервизоры и иниты.
А как десктоп системы запускать в данной парадигме?
Писать простыни шелл скриптов — так уже проходили это, отказались. Эволюционировали дальше, опять отказались, родили системд.
Вы предлагаете вернуться к простыням обратно? А зачем? Чтобы безопаснее было?
Fedora, десктоп, 30% запущенных сервисов задетачены, мне для них что надо, баш скриптами врапперы писать? А зачем?powerman
05.02.2019 00:31-1Не совсем понял, о каких таких специфичных для десктора простынях скриптов речь.
У меня 15 лет дома на десктопе runit. Да, в списке процессов болтаются всякие самозапустившиеся "сервисы" вроде
/usr/libexec/gvfs-udisks2-volume-monitor,/usr/libexec/udisks2/udisksd,gpg-agent,/usr/libexec/dconf-serviceetc. без нормального runit-супервизора. Это немного раздражает, но без веских причин, скорее просто по принципу "потому что тишина должна быть в библиотеке!". По факту у них просто собственный жизненный цикл, кто-то их автоматом запустил когда они понадобились, и если они крешнутся, то этот кто-то их и перезапустит когда они снова понадобятся. А если выключить Xorg, то они все будут убиты автоматом. В отличие от системных сервисов, которыми я нередко управляю вручную через runit, нужды вручную управлять этими "сервисами" у меня пока не возникало.sn00p
05.02.2019 00:45+1Самозапустившиеся, кто-то их автоматом запустил
, это как вообще?
Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.
В свое время только один инит скрипт, например для zookeeper, был строк под 200. Писало его человек 10 в общей сложности. Сколько времени убили, уйму просто. А могли бы зоокипер пилить вместо этого. Сейчас файл занимает пять строк и понятен любому человеку, а не только аутисту.powerman
05.02.2019 00:53-1Сейчас чтобы запустить сервис типа zookeeper не нужен файл и на 5 строк, достаточно
docker run --name some-zookeeper --restart always -d zookeeper.sn00p
05.02.2019 01:10+1Да, вот только чтобы докер заработал, надо дофига всего при загрузке проинитить. Настроить сеть, настроить оверлей, выделить сторадж, прикрутить iptables, поднять d-bus, поднять логгирование, разобраться с race condition при всем этом.
А только потом запустить в докере zookeper, не забыв указать ему переменные окружения. А потом разработчик с соседнего отдела приходит и говорит, там это, баг у нас походу, давай попробуем сменить файлуху вот тут в сервисе на reiserfs, например. Только тут надо на 300 машинах, там половина центос 6,8, вот тут вообще опенвз стоит, тут вот центос обновили, но не до конца. А вот тут машина грузится долго, нам полсофта надо переписывать, че за хрень? А ты ему, щас погоди, чувак, давай через неделю другую приходи, следующие спринтов 10 твои, мне тут свой суперинит поправить надо.
Есть серверы, где докер, например, не заработает, тут как быть? Например, там убунта, в которой уже выпилили апстарт. И которую обновить нельзя, там кривой aufs с проблемами с dir permissions + отключен коннтрак.
Мир он такой, многогранный. Именно поэтому там существует и runit, и upstart, и по старинке, и systemd одновременно. Если вам чего-то тут не нравится или не надо, всегда найдется несколько сотен тысяч человек, которые думают по-другому.
pal666
05.02.2019 01:13+1это подмена понятий. файл нужен, просто он уже в образе докера. точно так же, как и юнитфайлы уже есть в системе, достаточно systemctl start zookeper. что, кстати, короче заклинания для докера
gecube
05.02.2019 08:23Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.
пардон, докер это вообще не про это. Даже если вы упакуете все сервисы в докер, то такую цепочку в нем не реализовать. Только если не привлекать сторонние утилиты. docker-compose? Увольте, он ничего сложного не умеет. Получается опять возвращаемся ЛИБО к оркестрации (кубики+ансиблы и прочее), ЛИБО к systemd, но тезис коллеги выше в том, что если есть systemd, то докер уже не нужен, т.к. первый все уже умеет (изоляция, разделение ресурсов и much more). Паковать docker-контейнеры в systemd юниты можно, но при этом теряется часть прелестей самого systemd + много бойлерплейта.sn00p
05.02.2019 08:58Так это и не про докер кейс. Это про инит в целом.
что если есть systemd, то докер уже не нужен,
Это вы откуда такое утверждение взяли? Было утверждение, что systemd использует cgroups и этому есть свои причины, которые вам и привели неоднократно. Из-за этого, в том числе, использование докера необязательно, если вам нужны только cgroups.
Докер же — это не просто cgroups, это целый комбайн, там еще куча всего дополнительно намешано.gecube
05.02.2019 09:43Было утверждение, что systemd использует cgroups и этому есть свои причины, которые вам и привели неоднократно
И что? Пускай использует. Я не против.
Из-за этого, в том числе, использование докера необязательно, если вам нужны только cgroups.
Эм. По факту из всего вышеперечисленного докер решает только две задачи:
1. пакетирование приложений и их доставка. systemd это не умеет. Но это умеют системы SCM + пакетные менеджеры (последние есть во всех современных дист-х)
Ну, и все равно настраивать среду под докер и как-то инициировать стягивание новых версий образов нужно (scm?)
2. изоляция окружений. Т.е. чтобы не было взаимовлияния. Потому что держать те же несколько версий php/python на одной машине — кошмар. И, да, докер с этим справляется хорошо. Другой вопрос — а нужно ли это всегда.
Все остальное — автоперезапуск сервиса, зависимости между сервисами, ограничение по процу/памяти и пр. — systemd прекрасно отрабатывает.
Лучше скажите — что Вы планируете делать для совмещения докера и systemd? Ну, предположим, что докер-контейнеру нужен маунт нфс, т.е. уже нужно зависимости между разными сущностями строить.sn00p
05.02.2019 09:56+1Еще раз.
Утверждения были такие.
1. systemd умеет cgroups. Зачем это нужно, уже указали, не раз. В ответ на это наш коллега с «простой и понятной системой» с инит скриптом из 300 строк заявил, что ему это не надо, есть вот же докер, что еще надо.
На вопрос, что делать, когда докер по разным причинам запустить вдруг нельзя, наш коллега тактично отвечать не стал.
2. Докер не замена иниту и инит не замена докера.
Хотя наш коллега с «простой и понятной системой» и думает иначе.
Я знаю что такое докер, я ничего не планирую делать для совмещения systemd и докера. Зачем бы мне это надо было?
pal666
05.02.2019 01:19+1У меня 15 лет дома на десктопе runit
у меня в течение бОльшего времени дома на десктопе то, что идет с дистрибутивом. процесс написания скриптов/юнитфайлов аутсортится разработчикам дистрибутива. никакого беспокойства по поводу «скриптов обижают» не испытываюgecube
05.02.2019 09:47процесс написания скриптов/юнитфайлов аутсортится разработчикам дистрибутива
я честно скажу, что они это плохо делают, что для обычных инит-скриптов, что системд-юнитов. Возможно даже проблема не в разработчиках дистрибутивах как таковых (они попросту не могут знать специфику всего ПО), а в разработчиках конкретного приклада, который включается в дистрибутив. Но все равно от этого не легче.sn00p
05.02.2019 10:00+1Нормально они это делают. Если вам не нравится, можете сделать PR и поправить, кто вам не дает? Можете показать хоть один ваш issue в гитхабе на эту тему?
norguhtar
05.02.2019 10:03Embedded уже поддерживает systemd и да более того это заметно удобнее и позволяет выкинуть поддержку init и его утилит из busybox. В итоге размер бинарного кода меняется довольно слабо ;)
Stanislavvv
05.02.2019 09:17Вообще-то зависимости в runit таки можно сделать. Через прописывание `sv start $depends` в ./run
eugene08
05.02.2019 00:03а runit мониторит дочерний процесс? можно ли автоматически поднять упавший процесс?
powerman
05.02.2019 00:08Разумеется, все эти системы (daemontools/runit/s6) работают по одному принципу: сервис запускается в foreground (т.е. он при запуске не делает fork), т.о. процесс сервиса остаётся непосредственным child-ом утилиты-супервизора (supervise в случае daemontools, runsv в случае runit, etc.), и когда сервис крешится его супервизор моментально получает от ядра ОС SIGCHLD и перезапускает сервис. Никаких pid-файлов и уязвимости к race conditions (как в случае init.d-скриптов из sysvinit) здесь нет, всё работает 100% надёжно.
Gutt
05.02.2019 10:39Я понимаю, что очень велик соблазн написать SysV init script для systemd, но всё же:
[Unit]
Description=Test service
[Service]
ExecStart=/usr/bin/blalbla
KillSignal=SIGINT
KillMode=process
[Install]
WantedBy=default.target
Но проще не заморачиваться и не указывать ни KillMode, ни KillSignal, тогда они будут control-group и SIGTERM соответственно. Дети почти гарантированно не выживут (только если они не ушли в сискол навсегда), поскольку через TimeoutStopSec прилетает SIGKILL.
selivanov_pavel
04.02.2019 03:58> большие группы сообща проявляют общее презрения к systemd
> У нас нердов сложное отношение к изменениям
Ну конечно, всё сводится к психологической драме, а не к тому, что эти изменения создали проблемы там, где их раньше не было.
Да, systemd решает задачи, которые не мог решать старый init, и проходилось городить костыли. Ну и унификация между дистрибутивами конечно радует.
Но в то же время systemd привнёс дополнительную сложность и хрупкость туда, гдё её раньше не было. При этом он безальтернативен: на локалхосте можно использовать хоть arch + openrc хоть самосборный LFS + <любая дикая экзотика>, но на сервере будет какой-нибудь Debian- или RedHat-like LTS, и там systemd неизбежна. То есть с точки зрения «нерда» ситуация выглядит так: вот тут раньше был простой как топор кусок системы, о котором можно было даже не задумываться. Теперь тут будет сложная фиготень, которая много чего умеет, но иногда ведёт себя непредсказуемо.
Ещё раз: проблема не в том, чтобы что-то освоить. Не самый сложный в мире софт, в конце концов. Дело в том, что с init проблемы в духе «journald иногда начинает есть 100% проца» или «resolved странно себя ведёт» невозможны в принципе. А 95% новых крутых возможностей мне, например, не нужны. timesyncd всё равно хуже openntpd или chrony, journald по возможностям гораздо слабее rsyslog или syslog-ng.powerman
04.02.2019 04:34+1Странности поведения это плохо, но вот проблемы с безопасностью в таком элементе системы это намного хуже. И количество проблем с годами только увеличивается, что является довольно естественным следствием увеличения сложности.
norguhtar
04.02.2019 20:36Для этого надо просто оттуда выгнать Поттеринга и все ок будет :) Как это призошло с PulseAudio.
pal666
04.02.2019 23:42о бревне в глазу
список не полный, т.к. не включает всего, что запускается из баша и вообще игнорирует 800-фунтовую гориллу «написанный кривыми руками скрипт»powerman
04.02.2019 23:58-1Смешно. Попробуйте, ради спортивного интереса, сравнивать продукты из одной категории с systemd: daemontools, runit или s6 — на всех троих вы найдёте ровно одну смешную CVE 2006-го года для runit. При использовании daemontools, runit или s6 для запуска системных сервисов в памяти не находится ни одного процесса bash или sh (имеется в виду когда они уже запустились, т.е. 99.999% времени работы системы).
Что касается проблем с bash — даже не подумаю их оспаривать. Кстати говоря, автор s6 создал язык execline, который как раз позволяет решить проблему портабельности sh-скриптов (а заодно и уязвимостей bash), и даёт возможность писать ./run-файлы сервисов без использования sh.
pal666
05.02.2019 00:26+2постойте, все три продукта запускают баш (это /bin/sh на упомянутом выше редхате). т.е. игнорировать уязвимости баша нельзя. и ни один из них не состоит в одной категории с системд-проектом(ваш список уязвимостей не ограничен системд-пид1). системд-проект это базовая система, в одной категории с ним стоят наборы из десятков программ, сдобренных кривыми скриптами.
Gutt
05.02.2019 10:53daemontools, runit или s6 — на всех троих вы найдёте ровно одну смешную CVE 2006-го года для runit
Отлично! Значит, тот http-сервер на bash+netcat, что я написал пять лет назад, самый безопасный в мире! Постойте, или это потому, что он мало где используется и к нему не приковано внимание специалистов по безопасности?
mwambanatanga
04.02.2019 06:38Райс отказалась защищать стиль общения Пёттеринга, но сказал, что нельзя не восхититься силой воли и решимостью Пёттеринга
Надо бы определиться…
P.S.: Моя сестра в детстве, знакомясь с другими детьми, задавала им два вопроса: «Как тебя зовут?» и «Ты мальчик или девочка?». Бенно Райс это именно тот случай, когда по имени невозможно определить пол.
onborodin
04.02.2019 16:15>К моменту выхода 4BSD у Unix и появился правильный демон getty
getty никогда не стартовал как демон.
DESCRIPTION
The getty utility is called by init(8) to open and initialize the tty
line, read a login name, and invoke login(1).
>Старый init мог только запустить сервис, но после этого
init не запускал сервис.
init запускал стартовые сценарии, а те запускали демонов.
которые самостоятельно деали fork/setuid.
реализовали ли демоны сервисы или нет, было совершенно вторым делом.
демон получал родителя процесс 1.
все что было необходимо — запустить процесс, при необходимости оторвать от терминальной линиии и поменять uid/gid, записать pid, иметь возможность послать сигналы kill/stop/hup/etc.
вместо этого ветвистая клюква из 600 файлов и пары сотен симлинков, которая еще и на своей шине висит.
там, где хватает простых скриптов и утилиты daemon.
pal666
05.02.2019 01:03+3init запускал стартовые сценарии, а те запускали демонов.
а когда надо было запустить/рестартануть демона на работающей системе, то стартовые сценарии запускалиь рутом из его рабочего шелла. и наследовали все окружение(не только переменные, все параметры процесса вроде лимитов и т.д) и при определенном выстраивании звезд все взрывалось. но не всегда, часто все работало и поэтому до сих пор есть люди, думающие, что это может работать в принципе.
вместо этого ветвистая клюква из 600 файлов
если у вас 600 юнитфайлов, у вас было бы 600 глючных стартовых сценариев с простынями копипасты
еще и на своей шине висит
это не его шина. шина появилась гораздо раньше. не для того, чтобы насолить тем, кто привык запускать скрипты руками, а для того, чтобы избежать 600 криворуких реализаций ipc. конкретная реализация шины не лишена недостатков(повторюсь, они были и до системд), ведется работа над более лучшим вариантом
там, где хватает простых скриптов и утилиты daemon
эти скрипты сложные (*), правильно работают только если повезет и хватает их только если игнорировать все ситуации, в которых их не хватает
*) сравнение сложности первого попавшегося скрипта с юнитфайлом:
простой скрипт
сложный юнитфайл
и не забываем, что простой скрипт включает
. /etc/rc.d/init.d/functions
и
. /etc/sysconfig/networkonborodin
05.02.2019 08:06-2>эти скрипты сложные
даже не знаю что сказать…
>и при определенном выстраивании звезд все взрывалось.
FreeBSD/NetBSD/OpenBSD — c 1994 года ничего не взрывается.
И с лимитами все нормально.
Я из практики.
Может у товарищей руки не оттуда растут?
onborodin
05.02.2019 09:48-2Минусуют. Обиделись значит. Правда глаза колет =)
sn00p
05.02.2019 10:15+1Нет, минусуют из-за другого. Сейчас 2019 год, не 1994.
Сколько сейчас доля FreeBSD/NetBSD/OpenBSD в интернете?
Как скоро я смогу там запустить Clickhouse, например, добавить еще 20 фронтендов, пяток базенок mysql в HA, добавить немного мониторинга и автоматическое скалирование в случае изменения метрики, которая состоит из нескольких параметров, вычисляемых lua скриптом, который встроен в балансировщик? Часть системы надо еще разбалансировать по географически регионам, потому как клиенту важно получить ответ по наиболее коротким проводам. Часть системы в облаках надо разместить разного рода, потому как по стоимости это будет подешевле, чем свою SDN строить.
понимаете про что я?onborodin
05.02.2019 11:28>Нет, минусуют из-за другого.
— Я крут, потому что я имею крутой инструмент X
— Он критикует инструмент X, следовательно меня.
Это старо как генный код. Или стокгольский синдром.
>Как скоро я смогу там запустить Clickhouse, например, добавить еще 20 фронтендов
Может таки бек-эндов? Вы таки определитесь, что где, и причем здесь init =)
У меня без проблем до 7-10 «бекэндов» на одной системе. Некоторые созданы мной же. На node, perl, ruby, java.
Никаких проблем с интеграцией.
> Часть системы надо еще разбалансировать по географически регионам
Это вообще не относиться с старт-стоп подсистеме, только очень косвенно.
У вас каша из мух и котлет.
>понимаете про что я?
Про системный бардак в разработке и архитектуре там где вы работаете?
Не?sn00p
05.02.2019 11:37+2Я вам конкретные вопросы задал
Сколько сейчас доля FreeBSD/NetBSD/OpenBSD в интернете?
Как скоро я смогу там запустить...
Вы постеснялись почему-то ответить. Вместо этого занимаетесь демагогией про генный код. Зачем?
init здесь при том, что все вышеописанное предполагает одновременное использование минимум пяти десятков разных сервисов на каждом сервере, общим количеством более сотни, часть из которых вам вообще не принадлежит.
Мы до бекендов еще даже не дошли, давайте с фронтендами хотя бы закончим.
Как вы будете решать эту проблему с помощью FreeBSD/NetBSD/OpenBSD, где у вас c 1994 года ничего не взрывается?onborodin
05.02.2019 11:43-1>Сколько сейчас доля FreeBSD/NetBSD/OpenBSD в интернете?
>Как скоро я смогу там запустить…
Ну ладно, я старательно намекал.
Вы, сэр, не запустите там ничего по причине своей системной некомпетентности. Надеюсь, исправимой.
К пониманию критериев компетенций www.ecompetences.eusn00p
05.02.2019 11:46Ответов на два моих простых вопроса и финальный третий, я так понимаю, не будет. Именно поэтому я некомпетентен. Ну акей, кто бы сомневался.
Вопросы о моей компетенции я оставлю своим работодателям и партнерам все же. Вы бы лучше о своей позаботились.onborodin
05.02.2019 12:03-1>Ответов на два моих простых вопроса, я так понимаю, не будет.
А зачем отвечать на дурацкие вопросы? Это уже что-то в ключе «разделение бреда».
Ты бредовым потоком мысли пишешь про какие-то проекты, которые ты даже связно описать не можешь, потом прилепливаешь к этому статистику, потом ставишь знак вопроса, и надеешься что тебе кто-то ответит, магия сработает, потом ты win-win, и твоя картина мира станет на место.
Нафик-нафик.
PS
Вот уж не знал, что ключевым моментом в проекте станет написание старт-стоп скрипта.
«географически распределенного старт-стоп скрипта» =)sn00p
05.02.2019 12:05Сколько сейчас доля FreeBSD/NetBSD/OpenBSD в интернете?
это дурацкий вопрос? Как запустить на этом всем что-то сложнее мейлрелея и фтп — дурацкий вопрос?
Хехе. Что же в них дурацкого?
Я троллей не кормлю, кстати, так что предлагаю на этом и завершить. Идите погружайтесь в свое чувство собственного величия где-нибудь в другом месте.onborodin
05.02.2019 12:35-3>это дурацкий вопрос? Как запустить на этом всем что-то сложнее мейлрелея и фтп — дурацкий вопрос?
Это из реального проекта-продукта.
# cat dbmaster.in
#!/bin/sh
# PROVIDE: dbmaster
# REQUIRE: LOGIN
. /etc/rc.subr
name=«dbmaster»
rcvar=«dbmaster_enable»
pidfile="@APP_RUNDIR@"/dbmaster.pid
command="@prefix@/sbin/${name}"
command_args=""
procname="@prefix@/sbin/${name}"
load_rc_config ${name}
: ${dbmaster_enable:=«NO»}
run_rc_command "$1"
В продукте-программе предусмотрен хандлер сигналов HUP, KILL, STOP и прочих по мере необходимости.
Мастер процесс пишет свой pid в файл.
Исполняет fork(), setuid().
Для тех интерпретаторов кто не имеет такового есть другие решения.
Сделать демон — работы на 20 строк + в типовом скрипте поменять две-три строки.
У вас проблемы c «OK Google: start daemon freebsd»?
onborodin
05.02.2019 12:51-2PS
Для примера, вот для node библиотека-заготовка сделать демон:
github.com/onborodin/ng-lorem/blob/master/backend/daemon.js
Здесь старт-стоп скрипт:
github.com/onborodin/ng-lorem/blob/master/backend/rc.d/lorem.in
Что составляет примерно 0.01% от более-менее проекта.
Сложно, да?mayorovp
05.02.2019 13:05+1И по копии вот этого в каждой программе? Да, сложно. Особенно если найти ошибку в подобном коде — тогда-то и оказывается, что исправлять её во всех проектах куда бойлерплейт был скопирован — сложно…
onborodin
05.02.2019 13:13-2>И по копии вот этого в каждой программе?
>Да, сложно.
«fork() в каждой программе-демоне. Это сложно!»
ОMG. ОMG. ОMG.
Там 30 строк. Модуль. Делается 1 раз. На 10 лет. Вызов — 5 строк.
Невыносимо трудно найти ошибку в 30 строках.sn00p
05.02.2019 15:09+3Хехе
Добавляем условия, которые в systemd решаются очень сложными для понимания и длинными двумя строками.
After=network.target
И уже все не так радужно, ога? Да и redis во FreeBSD так нормальный и не завезли, так что придется его еще собрать.
Wants=redis.service
Добавляем еще
CPUAccounting=true
CPUQuota=10%
MemoryAccounting=true
MemoryLimit=50M
И становится уже интереснее.
у вас там вот это зачем, кстати?
const path = require('path')
Почему таймауты 100 и 500, а не 200 и 300?
Вот и все у вас так, через назад.onborodin
05.02.2019 15:29-3>Добавляем условия Wants=redis.service
require: «нуждаться, иметь надобность»
# REQUIRE: redisdb
#…
man rc
>Почему таймауты 100 и 500, а не 200 и 300?
Да перепиши как лучше считаешь, в чем проблема-то?
Но ты ж не для учиться спрашиваешь или применить, а для докопаться до столба.sn00p
05.02.2019 15:37+2А чем wants от require отличается, вы таки не осилили изучить, ога? Зря.
С таймауатми понятно, они тут по количеству лампочек в потолке, акей.
Остальную часть сообщения вы опять тактично проигнорировали.onborodin
05.02.2019 15:47-3Скажи своему смарфону:
ok google freebsd process limits
Он тебе расскажет.sn00p
05.02.2019 15:59+2это вот так надо делать, ога?
rctl -a jail:httpd:memoryuse:deny=2G/jail
или как? Потому как иных лимитов я не нашел для процессов.
А как это добавить вот к вашему коду из 30 строк? Там релоад можно будет сделать? Или только рестарт?
А если процесс запущен из-под юзера с одними лимитами, а rctl задаст другие, что будет? Как вообще проверить это при старте системы? У меня что-то в телефон не влазит вся инфа эта, можете вкратце описать? Или опять сольетесь? Да вы не переживайте, у меня много еще вопросов.onborodin
05.02.2019 16:06-3Да, я сливаюсь. Курсы по системной архитектуре два квартала вперед и налево за углом, 2000 EURO за недельный курс.
Удачи!sn00p
05.02.2019 16:16Cистемная архитектура тут причем? А чего системная архитектура-то? Там много курсов про системную архитектуру, вы на каких были? Вот там есть, например, системная архитектура ПО, но это вроде не оно.
На каком конкретно рассказывают про костыли в rc скриптах FreeBSD?
pal666
05.02.2019 11:37+1даже не знаю что сказать…
хочется сказать, что юнитфайл сложнее, но не выходит?
Я из практики.
некоторые на практике в русскую рулетку выигрывали. это как-то свидетельствует о безопасности упражнения?onborodin
05.02.2019 12:25-2>некоторые на практике в русскую рулетку выигрывали
бред какой-то.
программы-демоны в unix стартуют, работают, останавливаются.
а там уже кто-как их написал.
качественно написанные программы работают хорошо.
амен.
>хочется сказать, что юнитфайл сложнее, но не выходит?
Нет. Что systemd нерационален и монструозен как старт-топ подсистема.pal666
06.02.2019 00:54бред какой-то.
у вас во фразе «я не понял» несколько ошибок
программы-демоны в unix стартуют, работают, останавливаются.
но не всегда
Нет.
так проще юнитфайл или сложнее? я запутался
systemd нерационален и монструозен как старт-топ подсистема.
системд это далеко не только старт-стоп подсистема. ну и о рациональности лучше судить тем, кто может отличить простой файл от сложногоonborodin
06.02.2019 10:05-2> ну и о рациональности лучше судить тем, кто может отличить простой файл от сложного
несомненно, вы умны, и способны отличить сложный файл от простого.
например, по количеству букв.
mxms
05.02.2019 12:05-1эти скрипты сложные
даже не знаю что сказать…
Я бы сказал, что не освоившим элементарный синтаксис POSIX shell не место в профессии. А если добавлю, что init / rc куда как гибче и понятнее systemd меня ластоногие вообще втопчут в лёд… :)
mayorovp
05.02.2019 15:31+1Скажите, а приколы вроде вот такого из комментария выше — это точно элементарный синтаксис POSIX shell? А то в учебнике почему-то написано, что со знака # начинаются комментарии...
# REQUIRE: redisdbonborodin
05.02.2019 15:57-3>это точно элементарный синтаксис POSIX shell?
Нет. Это не элементарный синтаксис.
Это особый синтаксис для продвинутых разработчиков после окончания колледжа.
Обычно о нем узнают после требований старших писать комментарии для кода.
Некоторые продвигаются дальше и даже разрабатывают синтаксис для автоматической генерации описаний API (как завещал великий Дональд Кнут), и даже, о боже, самого кода.
PS
Не, я рад, что вы продвигаетесь в обучении. За один день и узнали столько новых слов!mayorovp
05.02.2019 16:05+1Интересно, какой сценарий "узнавания" этой информации? Вот, допустим, "продвинутому" разработчику после колледжа старшие коллеги сказали написать комментарии для кода на C++. После этого он что, идёт читать маны по rcorder? Где в вашем комментарии логика?
onborodin
05.02.2019 16:11-3>Интересно, какой сценарий «узнавания» этой информации?
Не поверите, сэр.
Нужно начинать с книг, сэр.
Как говорят последние 50 лет, RTFM, сэр.
Попробуйте начать с RTFM, сэр.mayorovp
05.02.2019 16:14+1Да, в книгах написано всё, как и в манах (обычно).
Но это никак не сделает rcorder обязательным для изучения после колледжа всеми разработчиками, а REQUIRE — частью синтаксиса POSIX shell.
Если вы считаете как-то по-другому — возвращаю вам ваш RTFM.onborodin
05.02.2019 16:26-3Сэр, как взрослый человек, вы можете сами выбирать себе книги.
И даже сами придумывать слова!
Например, как взрослый разработчик, вы можете придумать синтаксис, описать его, написать синтаксический парсер, и даже опубликовать его!
И это даже может войти в руководство по системе!
И вам даже не потребуется читать RTFM по этому синтаксису!
Во всех остальных случаях, вынужден огорчить, RTFM все-таки потребуется.
pal666
06.02.2019 01:01+1Попробуйте начать с RTFM, сэр.
как далеко вы продвинулись в чтении мануалов по системд?onborodin
06.02.2019 10:11-1>как далеко вы продвинулись в чтении мануалов по системд?
вы предлагаете услуги по чтению «мануалов системд»?
как продвигается ваш бизнес? много клиентов?mayorovp
06.02.2019 10:20Нет, это вы предлагаете услуги по чтению «мануалов rcorder». Только клиентов у вас почему-то нет… :-)
sn00p
06.02.2019 10:59Зато у него есть много прекрасного на его сайте )) Очень поднимает настроение, рекомендую )
onborodin
06.02.2019 13:01…
Де Вальвер. О, жалкий фат!
Я так его пугну, что он не пикнет даже.
(Подходя к Сирано.)
Ваш нос… Hy, в общем… крупноват…
Сирано.
Да. Он крупней, чем красноречье ваше,
А я бы о таком, заметьте,
О выдающемся предмете
Острот набрал бы целые тома,
Меняя жесты и топа…
Вот, например, из не особо острых — Тон описательный — так шутит новичок:
Как называете вы этот полуостров,
Который вырос между ваших щек?
Развязный тон, каким острят друзья:
Вам из стакана пить нельзя — Побьет ваш нос посуду вашу!
Позвольте подарить вам чашу?
Или почтительно-умильный;
Вы этой башнею фамильной
Давно владеете?
Наивный: С дальних мест
Вы этот монумент везли для дам столичных?
Любезный: Сударь любит птичек?
Он приготовил им вместительный насест!
Ехидный: Это что? Крючок для шляп? Удобный!
Платить не надо в гардеробной!
Тон нежный: Боже мой! От дождичка и ветра
Вы заказали зонтичек ему?
Тон удивленный: Извините, это — Вам одному?
Доброжелательный: В пылу житейских гроз,
Фиаско потерпев в каком-нибудь вопросе,
Вам нелегко повесить нос,
Зато легко повеситься на носе!
Язвительный, чуть в сторону и косо:
Но, сударь, вам решительно везет:
Не видя дальше собственного носа,
Вы все же видите широкий горизонт!
Практический: Советовать вам смею
Для носа вашего устроить лотерею;
Я вам скажу с открытою душой,
Что получивший вещь такую
Имел бы выигрыш большой,
Имея радость небольшую.
Вот так острить могли б вы наобум,
Когда бы знания имели или ум.
Но нет y вас ума и так немного знаний,
Что вы не знаете еще, что вы дурак.
Эдмон Ростан.
Сирано де Бержеракsn00p
06.02.2019 13:07Вы на хабре начали снова писать комментарии с 5 февраля 2019 года, уже умудрились нахамить десятку пользователей, засрать и заспамить своими некомпетентными комментариями, ничего общего с реальностью не имеющими, кучу постов. Схлопотать кучу минусов, в том числе и в карму, теперь закономерно начинаете всех дураками обзывать? Знаете какой следующий этап?
onborodin
06.02.2019 13:17>теперь закономерно начинаете всех дураками обзывать?
Это цитата из очень хорошей пьесы, но раз ты сам себя самоидентифицировал, то ничего не могу с этим поделать.
Возможно, только предполагаю, ты переоцениваешь ценность как себя, так и этого «диалога».
onborodin
06.02.2019 11:47>Нет, это вы предлагаете услуги по чтению «мануалов rcorder».
Вы, сэр, сначала выдумываете себе, потом этому радуетесь.
Это хорошо, что в вашей жизни есть счастье, сэр.
mxms
05.02.2019 19:10-1Это относится к фреймворку rc.d во FreeBSD, кстати весьма простому, но это POSIX shell позволяющий реализовать любую логику, которая вам только может быть необходима, а не ту, которую решили использовать за вас хотите вы этого или нет.
mayorovp
05.02.2019 19:49+1Независимо от его простоты он не является POSIX shell и требует дополнительного изучения. И если POSIX shell действительно должны знать почти все — то фреймворк rc.d во FreeBSD знают только FreeBSD-админы.
Учитывая, что в каждой дистрибутиве *nix что-то своё да выдумали — да, скрипты инициализации становятся сложными.mxms
05.02.2019 20:29-1Вы так пишете, как будто нет этого безумного зоопарка из всевозможных клонов Linux, тонкости которых, внезапно, тоже надо изучать.
Вообще, я думаю что systemd уже начал геноцид расово-неправильных обитателей этого отмороженного GPL континентa, адептом чего и является автор статьи, и это ни к чему хорошему, в итоге, не приведёт.pal666
06.02.2019 01:10+1это POSIX shell позволяющий реализовать любую логику, которая вам только может быть необходима
системд позволяет запускать все, что угодно, включая посикс шелл, реализовывающий любую логику
безумного зоопарка из всевозможных клонов Linux, тонкости которых, внезапно, тоже надо изучать
системд как раз приносит порядок, изучать надо только системд
Вообще, я думаю что systemd уже начал геноцид расово-неправильных обитателей
системд это просто программа, она ничего начать не может. я вижу, вы недовольны тем, что есть такая программа, которая приносит другим людям много пользы, но почему это вас так злит? вы не хотите, чтобы другие люди извлекали пользу?
отмороженного GPL
вас гпл в детстве покусал?
адептом чего и является автор статьи
автор статьи является разработчиком фрибсд, как вам такой нож в спину?
это ни к чему хорошему, в итоге, не приведёт
что вас сильнее огорчает — отмороженность контента или его геноцид?mxms
06.02.2019 11:26системд как раз приносит порядок, изучать надо только системд
Да-да, именно об этом я и писал. Деградация профессии.
вы недовольны тем, что есть такая программа,
Вообще, меня вся эта возня больше интересует ну примерно как естествоиспытателя, который наблюдает за жизнью колонии каких-нибудь бактерий. То есть любопытно, можно выявлять зависимости и делать прогнозы.
Меня беспокоит лишь только чтобы эта бактерия не распространилась слишком широко уничтожив большую часть остальной жизни. Потому что разнообразие это необходимое условие для развития и эволюции.
вас гпл в детстве покусал?
Как атеиста меня в некотором роде, да, огорчает любое проявление религиозной веры, а GPL теперь для некоторых это стало чем-то вроде секты. На Habr это выражено не так ярко, что не отменяет самого факта.
pal666
06.02.2019 01:00Я бы сказал, что не освоившим элементарный синтаксис POSIX shell не место в профессии
а неосвоившим элементарный синтаксис юнитфайлов?
А если добавлю, что init / rc куда как гибче
то я отвечу, что шелл скрипты отлично запускаются из системд, он вообще изначально автоматически умел работать в системе, где еще скрипты из init.d не переделали в юнитфайлы, переделывание в юнитфайл это просто способ получить еще больше плюшек.
и понятнее systemd
место ли в профессии тем, кто не осилил элементарный системд?kt97679
06.02.2019 01:36Systemd не элементарный: www.ocsmag.com/2016/10/19/systemd-progress-through-complexity
gecube
06.02.2019 01:45+1Во-первых, статья 2016-го года.
Во-вторых, автор столкнулся с вполне конкретным кейсом, который уже упоминался. К тому же, я допускаю, что журналд не так часто ломается. А если ломается, ну, уже есть опыт — куда копать (но это не имеет отношения к сложности самой технологии, а к степени ее внедрения и распространенности)
В третьих, автор — нытик. Рассказывает какой плохой системд и как хорошо жилось с инит-скриптами.
В четвертых, инит скрипты хоть и проще (проще начать их писать абы как по примерам), но что-то сложное на них сделать… и к тому же они рождают весьма странных кадавров.
Короче — мимо. Но спасибо за попытку.kt97679
06.02.2019 02:26Во-первых, статья 2016-го года.
Простите, а что это меняет?
Во-вторых, автор столкнулся с вполне конкретным кейсом, который уже упоминался. К тому же, я допускаю, что журналд не так часто ломается. А если ломается, ну, уже есть опыт — куда копать (но это не имеет отношения к сложности самой технологии, а к степени ее внедрения и распространенности)
Автор столкнулся с невозможностью восстановить систему.
В третьих, автор — нытик. Рассказывает какой плохой системд и как хорошо жилось с инит-скриптами.
Зачем же вы сразу ярлыки лепите? Автор в недоумении, почему внедрение новой технологии усложняет его жизнь. Думаю если бы systemd работал как часы то и подобной статьи не было бы.
В четвертых, инит скрипты хоть и проще (проще начать их писать абы как по примерам), но что-то сложное на них сделать… и к тому же они рождают весьма странных кадавров.
Плохо можно писать на любом языке, шелл тут не исключение.
Короче — мимо. Но спасибо за попытку.
Да пожалуйста, я не собираюсь вас переубеждать.
onborodin
06.02.2019 12:35>что-то сложное на них сделать…
факт остатется фактом. один амбициозный разработчик привлек себе фонд, сделал проект, договорился об интеграции.
«эй, парень, тебе не нравиться мой продукт? верни товар, забери деньги»
написать старт-стоп-управление систему, 2 месяца-1человек и навскидку 40-60 страниц С кода, startd + startctl с общением через сокет, но таки никто толком и не способился довести нечто подобное до конца за 15 лет.
все зарабатывали для себя.
публичные продукты как транспорт и элемент оферты.
когда это понимаешь, все cтановится на места.
onborodin
05.02.2019 08:18PS
Если чего, то с Linux я начинал в 1994 году.
У системо-строителей всегда было много пафоса,
но мало системности.
Вместо пересмотра системы по принципу KISS, часто один костыль заменяли другим.
Ну а «подопытные хомячки» из пользователей вынуждены только восхищаться величием очередного системо-строителя.
Потом системо-строитель куда-то исчезал, обычно в коммерческую контору.
dmitrmax
04.02.2019 20:10Кто-нибудь может посоветовать хороший мануал, где описаны все концепции systemd, его утилиты и вот это всё?
Tanner
04.02.2019 22:16+1Мне помогло в своё время wiki.archlinux.org/index.php/Systemd
gecube
04.02.2019 22:26+3Вот чем Арчеводы сильны — так это документацией. Реально спасала неоднократно!
dmitrmax
05.02.2019 09:26Это набор готовых рецептов, которые позволяют сделать вам типовые таски без вникания в суть, осознания и систематизации полной картины, которую из себя представляет systemd. Это нельзя считать нормальной докой.
Tanner
06.02.2019 06:36А нам не надо осознания, мы не строим свои дистрибутивы и не разрабатываем systemd. Нам надо именно что типовую таску ? запустить свой процесс и перезапустить его, если упал.
pal666
04.02.2019 22:41+1systemd System and Service Manager
можно начать с раздела The systemd for Administrators Blog Seriesdmitrmax
05.02.2019 09:30То есть лучшая дока на одну из самых важных частей системы — это набор статей для блога? Серьезно? Я-то ожидал что-нибудь хотя бы уровня Git Book.
pal666
05.02.2019 11:45+2там доков много. не нравится начинать с блога — начните с манов
dmitrmax
05.02.2019 12:01+1маны можно не «там» читать. ман — это документация к конкретному бинарю/конфигу systemd. Он не даёт понимания того, как всё это связано, переплетено и взаимодействует друг с другом. Точно так же от чтения man на конкретные команды git не формируется понимания того, как работает git и какие там существуют best current practices и т.д.
pal666
06.02.2019 01:24+1а вы попробуйте. в man systemd есть раздел concepts. можно на любом сайте манов читать, если вам этот не нравится. можно видео презентации смотреть(тут есть ссылки). или надо обязательно, чтобы оглавление совпадало с гитбук?
naryl
04.02.2019 21:05Когда речь заходит о модульности апологеты и противники systemd просто говорят о разных вещах.
Апологеты: systemd модульный. Вот по бинарю на каждый модуль: systemd, udev, journald…
Противники: systemd монолитный. Я не могу взять систему с systemd и заменить отдельно init и rc на, например, SysVInit и OpenRC соответственно, оставив при этом остальные модули, такие как udev и journald.
И хоть формально оба правы, практический смысл утверждения апологетов systemd от меня ускользает.pal666
04.02.2019 22:48+2правы только апологеты системд. можно взять кусок системд, он зависит не от системд, а от опубликованного интерфейса, реализовать интерфейс может кто угодно(другое дело, что чаще дальше криков дело не идет, но примеры альтернативных реализаций есть. упомянутый удевд используется всеми поголовно)
evgenyk
04.02.2019 22:57-1Не буду лезть в сравнивание systemd и скриптов. Но вот тенденция тащить всю функциональность под себя, в одну бинарную программу мне решительно не нравится. Очень уж напоминает Виндовс. ИМХО, не нужно догонять и обгонять Виндовс НТ, он уверенно движется в направлении кладбища. Нужно ли это Линуксу?
А то я видел и много заявлений о необходимости реестрв в Линуксе.gecube
04.02.2019 23:22+1Где одна бинарная программа? Вы чего? Systemd состоит из целой плеяды программ.
Касательно реестра — он уже здесь. Где по-Вашему хранятся настройки кедов и гномов, если не в подобии реестра ????evgenyk
04.02.2019 23:33-1Вы чего? Systemd состоит из целой плеяды программ.
Возможно, суть моих опасений от этого не меняется
Касательно реестра — он уже здесь. Где по-Вашему хранятся настройки кедов и гномов, если не в подобии реестра ????
Ну, слава богу, пока есть возможность сидеть не под кедами или гномом. Хотя вроде как в гноме настройки храняться в XML файлах. Или я опять ошибаюсь?pal666
05.02.2019 00:19+2Возможно, суть моих опасений от этого не меняется
если опасения это «тащить всю функциональность в один гит репо», то вам надо посмотреть на модель разработки фрибсд(той самой, которая юникс, о потором забыл системд) и ужаснуться. это про системд-проект.
а основным мотиватором системд-пид1 был лончд из макоси(тоже юникс, кстати) — на макось равняться православнее, чем на винды?gecube
05.02.2019 08:32МакОсь с точки зрения пользователя прекрасна. Лучше, чем все эти винды, линуксы и прочее.
С точки же зрения обслуживания… Ну, такое себе. Система сложная, но я выше писал, что сложная система может быть простой в эксплуатации, скрывая все эти ужасы от юзера. Вопрос в том, что будет когда она сломается )
тащить всю функциональность в один гит репо
можно пояснить? Я против монореп ничего не имею. Это вообще больше религиозный вопрос, т.к. и монорепы, и куча маленьких микрорепозиториев имеют свои проблемы. И опять же повторюсь, что и для тех, и для тех нужен свой собственный тулинг, чтобы с ними эффективно работать.
evgenyk
Ну, слава богу, пока есть возможность сидеть не под кедами или гномом. Хотя вроде как в гноме настройки храняться в XML файлах. Или я опять ошибаюсь?
а какая разница КАК они хранятся, извините? Они могут быть в виде единой БД, могут быть россыпью относительно стандартных xml в единой структуре каталогов. Вот посмотрите — dconf
Есть еще такая история, но что она редактирует — я вообще не в курсе.evgenyk
05.02.2019 12:10а какая разница КАК они хранятся, извините?
Мы же про реестр виндов? Самый ужас в том, что он хранится а бинарнике, который ничем не редактируется. XML конечно тоже ужас, но все-таки не ужас-ужас.
Tigran_Sablezubov
05.02.2019 08:57То, что systemd что-то знает о cgroups, является не только его плюсом, но и минусом. Например, он был замечен за удалением созданных не им cgroups, имена которых, судя по strace, были им получены через readdir.
В этом главный недостаток systemd в сравнении с init-скриптами. systemd исходит из того, что человек, использующий его, обязан вникать в его «идеологию» и конфигурацию, чтобы systemd ему ничего не ломал.gecube
05.02.2019 09:45Расскажите про кейс подробнее. Может просто стоит переложить все управление cgroups на systemd и не ломать голову?
(это примерно как в кейсе взаимного влияния iptables + docker + scm + vpn)
pal666
05.02.2019 11:07+1это не его идеология, это идеология cgroups, там только один хозяин может быть. The New Control Group Interfaces
mayorovp
05.02.2019 12:45По вашей ссылке:
I don't use systemd, what does this mean for me?
Nothing. This page is about systemd's cgroups APIs.pal666
06.02.2019 01:30если вы не используете системд, то системд не сможеть трогать ваши сигруппы. это был вопрос с дистра без системд. что станет очевидно, если не отрезать из цитаты следующее предложение:
If you don't use systemd then the kernel cgroup rework will probably affect you eventually, but a different component will be the single writer userspace daemon managing the cgroup tree, with different APIs. Note that the APIs described here expose a lot of systemd-specific concepts and hence are unlikely to be available outside of systemd systems.
powerman
Попахивает Стокгольмским синдромом. Адекватно и корректно про трагедию systemd написано здесь: https://www.skarnet.org/software/s6/systemd.html (англ.).
gecube
Почему? Мне кажется, что по сути хоть нас и лишили выбора — systemd есть уже везде, но это не так уж и плохо. По крайней мере, стоимость поддержки зоопарка систем в виде centos/rhel/ubuntu/debian стала ниже. Юниты удобно и легко писать и отлаживать и можно забыть этот кошмар с init.d-скриптами в прошлом.
powerman
Кошмар с init.d для меня ушёл в прошлое в 2001 году, когда я собрал свой дистрибутив на базе LFS с запуском сервисов через daemontools. Правда, появился кошмар поддержки своего дистрибутива, но это решилось переходом в 2004 на Gentoo с использованием runit и в качестве init и для управления сервисами. 15 лет такой вариант Gentoo используется и на рабочих станциях и на серверах — никаких проблем нет, всё работает крайне надёжно и требует минимальной поддержки раз в пару лет (я про конфиги runit для загрузки ОС и/или сервисов).
Что касается запуска собственных проектов где-нить на AWS, то там запускается любой дистрибутив, под него ставится докер, и всё остальное происходит исключительно в докере — что там за дистрибутив на хосте и используется ли в нём systemd или что-то другое — уже без разницы, на хосте помимо установки докера разве что специфичным для дистрибутива способом запускаются обновления ОС.
gecube
Предлагаете все тащить в докер? И БД (монга, постгрес и пр.) тоже?
И если уж на то пошло:
И, да, докер — это уже прошлый день. Теперь модно CRI-O/containerd.
powerman
Да без разницы, какой дистрибутив, и без разницы, докер или что-то другое модное, суть в том, что то, что мы раньше ставили на сервера системными сервисами теперь ставится контейнерами. БД в докере работает ничуть не хуже, чем вне докера — volume с данными по сути подключается через bind mount каталога хоста, так что проседания производительности нет.
gecube
Спасибо, я в курсе.
Сам проводил измерения. Но есть нюансы ) дьявол в деталях.
Та же сетевая латентность при работе через докер выше. Для какого-нибудь хостинга или простого сайта это некритично, но для серьезных применений — так себе и нужно это учитывать.
С другой стороны — действительно, systemd позволяет все настроить так же. И даже зарезать сервисы по cpu/mem через те же cgroups. Нужно ли в этот зоопарк тащить ещё и докер, т.е. лишнюю сущность — ну, пускай решает сам )))
P.s. я уж не говорю какой это ад настроить файрволл на машине с докер-демоном, под управлением scm, да ещё и в роли vpn пира )))
powerman
Ну, я бы не сказал, что прямо ад. У меня на домашнем сервере 20 сетевых интерфейсов, часть разные локалки для изоляции, пара провайдеров, несколько клиентов openvpn, сервер openvpn, ну и докер (причём в нём несколько разных проектов, каждый в своей docker network) — настройки iptables у меня ручные, довольно сложные, но про докер там почти ничего — прописаны его подсети для антиспуфинга и немного фильтрации. Докер в iptables сам кучу своего добавляет, но этими правилами он рулит сам, и пока они ничего не ломали, хотя в моих условиях этого можно было ожидать.
А на нормальных серверах я обычно все докеры помещаю в общую сеть площадки (staging, prod, etc.), не доступную напрямую из инета, и файрвол настраиваю на сервере-шлюзе между этой сетью и инетом (ну и плюс в роли а-ля файрвола по конкретным докер-сервисам выступает конфиг nginx куда приходят запросы юзеров, фактически этот конфиг определяет, какие докер-сервисы публичные, а какие нет).
Что касается латентности — да, но это для абсолютного большинства проектов некритичный недостаток, зато бонусов от упаковки конкретных версий сервисов в образы докера и запуска их везде — от CI до машин разработчиков — намного больше.
gecube
Ваша точка зрения понятна. Спасибо. Я больше про кейсы, когда нужно перезагрузить правила netfilter и система управления файрволлом перезагружает все, после чего правила docker ломаются. Решение — перезапустить докер-демона, чтобы он все перестроил «как надо», но оно не всегда приемлемо (если нельзя делать даже минимальный простой). Либо управлять правилами файрволла полностью руками, а не пользоваться автоматикой, встроенной в докер.
В целом — преимущества от использования докера перевешивают недостатки и сложности, вносимые им. Но, к сожалению, мои разработчики вот эти вот граничные кейсы вряд ли осилят сами.
gecube
И ещё. Вопрос безопасности. Докер — это не про безопасность. Точнее — не про ту. Действительно, он реализует изоляцию контейнеров. Но она не железобетонная. Одна ошибка в ядре или демоне — и мы приплыли. Я больше про разделение прав пользователей. Гипотетический сценарий. Есть сервер. На нем докер. С ним работает 5 разработчиков. Хочется красиво распилить права. Но нет — для работы с докеросрачик нужен или рут-доступ, или добавление пользователя в группу docker. А последнее эффективно означает рутовые права на сервере (надеюсь, не надо пояснять почему?). В доверенной среде, когда все друг друга знают очень хорошо, это ещё куда ни шло. Но в прод такое тащить…
Есть несколько идей как такое победить. Например, можно определить структуру контейнеров изначально. Администратор ее формирует, а далее через sudoers даёт возможность выполнять команды docker пользователям только над своими контейнерами. Или, я тут позавчера случайно узнал, можно запустить два докер демона. Не изучал глубоко эту возможность, но для чего-то это может пригодиться.
Но лучше решение, конечно, — наверное, мигрировать в кубернетес или опеншифт. Он большой пласт этих вопросов закрывает
alexkuzko
Мы такую проблему решаем через деплой исключительно через настроенный CI/CD. И систему мерж реквестов, вероятность возможности навредить сильно снижается. В определенных случаях ещё и через Docker in Docker запускаем, ещё сильнее изолируя разработчиков.
Конечно, последним рубежом является выделение одного и более виртуального сервера на проект…
gecube
Попробуйте повоевать с дата-сатанистами на этот счет )))
Понятно, что можно отрезать все ручки, чтобы все было только автоматизированно. А на сервере пускать только по служебкам… Но это такое себе…
несомненно. Это еще и другие плюсы — например, удобнее считать косты, чем пытаться понять какая загрузка сервера в этом месяце была между проектами, если они его делят.
powerman
Безопасность практически всегда вредит удобству использования, но я полностью согласен с alexkuzko — деплой на сервера необходимо автоматизировать через CI/CD, доступ на сервера должен быть только у devops, разработчики, даже если они дата-сатанисты, должны вносить все изменения в код только через репо (причём право мержа в ветку, которая автоматом выкатывается на сервер, должно быть только у тимлида) и непосредственного доступа к докеру не иметь.
Либо, если это не прод, то можно поднять им отдельный сервер и дать полный доступ к нему, главное чтобы была возможность быстро грохнуть его и пересоздать с нуля за несколько минут, на случай его они его сломают.
gecube
Я, между прочим, Вам не перечу и поддерживаю точку зрения, что в идеальном мире нужно деплоить только через автоматизированный CI/CD. К сожалению, на этом пути много мин :-)
ну, или откатить состояние, если уж на то пошло.
gecube
насчет файрволла. Вообще идеальный кейс, когда платформа (ну, там амазон, гугль, или openstack в on-premise инсталляции — не важно) предоставляет примитивы vpc или файрволла на уровне сети. Тогда можно настроить группы безопасности и они имеют приоритет перед файрволлом внутри ВМ. И можно спать спокойно. В противном случае, повторюсь, настройка файрволла на машине докера похожа на попытки «скрестить ежа с ужом».
powerman
Ну, дома я действительно вынужден либо перезапускать докер после перегрузки правил iptables, либо менять правила по одному и ручками, не забывая при этом продублировать их в системный конфиг чтобы они сохранились после перезагрузки. А на серверах, как я уже говорил, проблема решается отсутствием отдельных правил iptables на серверах с докером, они настраиваются на шлюзе и/или в AWS VPC.
mspaint
>я уж не говорю какой это ад настроить файрволл
>Ну, я бы не сказал, что прямо ад.
Для типичного девопуса добавить правило после докера — непосильная задача. И сам докер писали, похоже, такие же девопусы — например очень типичное правило в таблице nat делающее redirect с 8080 по 80 порт докер не видит и просто тупо не работает. А типичный девопус сидит целый день над этой страшной проблемой и чешет голову, Я и Ж.
>зато бонусов от упаковки конкретных версий сервисов в образы докера и запуска их везде
Да, девопуса заставить обновлять что-либо невозможно. Даже если их сильно пинать за устаревший софт. Иначе бы пользовались yum-репозиториями вендора.
Мне вообще удивительно, как инструменты нищебродного хайлоада (т.е. когда нагрузок много, а денег мало) расползаются и в нормальное ИТ.
До докера уже много лет можно было делать live migration. С «могучим» докером это проблема. Софт писали так, чтобы он не падал раз в день, соответственно 100500 копий его запускать смысла не было. Вменяемое количество копий и деплой по группам можно делать средствами application server-а уже 15 лет. Журналы (логи) читали. А сейчас модно запустить 100500 копий, 30% из которых возможно как-то худо-бедно будут работать, потом терабайты логов грузить в специально развернутый очередной кластер и НЕ ЧИТАТЬ. И этот подход впаривают как передовой… (рукалицо)
gecube
Проблема не в том, что это непосильная задача, а проблема в том, что это сложности на ровном месте. Вы же понимаете, что правило из таблицы NAT имеет приоритет перед таблицей filter со всеми вытекающими. А еще отдельная история, когда правило в nat есть, в filter разрешающего нет и ты удивляешься почему контейнер одним способом доступен, а по прямому IP хоста — нет.
И только вот в каких-то последних версиях докера сделали наконец-то отдельные цепочки DOCKER-USER, хотя, честно говоря, не особо это и спасает.
это последствия тренда на то, что мы все запускаем на дешевом голимом ненадежном железе, потому что массовый рынок, а реально надежные и хорошие железки выдавливаются в очень узкий сегмент. Но производитель же ведь тоже не дурак и хочет кушать ) и поэтому наценка на эти узкоспециализированные, но очень надежные железки взлетает в космос (это типичная экономическая история). Касательно надежности еще момент, что всегда что-то может отказать. Независимо от количества девяток. И нужно иметь план Б. Будь-то восстановление с простоем, или что проще — иметь реплику и переключать на нее трафик.
mspaint
>что мы все запускаем на дешевом голимом ненадежном железе
Мы это кто конкретно? :) Я в прошлом сообщении уже проехался по нищебродно-хайлоадному подходу. Гугл, вроде, на коньсюмерном мусоре раньше крутился. Зачем натягивать сову на глобус (инструменты для решения проблем масштабирования гугла втюхивать всем)?
В нормальных конторах, даже не особо богатых, в стойках стоят серверы, с надежностью оных ничего не случилось. Сейчас наоборот виртуализация используется в 90% случаев, которая умеет live migration. А докер?!
И касательно железа, я наоборот не устаю поражаться — даже в плохих условиях (регулярные сбои системы охлаждения, а серверы работают как часы. Даже после многократных самоотключений по достижении +42С ambient. ;) У дисков SMART смотришь — 55-57 градусов. И живут по 7 лет. И тд и тп.
gecube
а) были исследования, которые показывают, что с ростом температуры количество отказов нарастает. Например, желтизна, но повод подумать.
б) есть куча историй про вылеты дисков. От перегрева тоже. И из «бракованных» (нет, мне не нравится, давайте назовем лучше — рискованных или ненадежных) серий и партий
в) у гугла были проблемы с отказами в ДЦ из-за перегрева. Из новостей нашел аналогичную историю про MS тыц.
г) по поводу железа — действительно нужно удивляться, что оно вообще работает. Это такая сложная инженерная материя ))) что прямо магия. И не нужно питать иллюзий по поводу надежности.
так виртуализация за эти и нужна, чтобы тоже компенсировать недостаток надежности железа + более гибкое управление ресурсами.
Докер — лив-миграцию сам не умеет (она ему и не нужна), но со всякими обвязками отчасти решает проблему.
и что? Мы живем в рамках некой парадигмы. И если все делают каким-то образом, то и нам тоже придется делать так же. Экономика-с.
Мы — все. Ну, может кроме каких-то специфичных применений из mission critical, но там есть соответствующие бюджеты.
mspaint
>так виртуализация за эти и нужна, чтобы тоже компенсировать >недостаток надежности железа + более гибкое управление
>Докер — лив-миграцию сам не умеет
Итого, спрашивается, а зачем нужен докер (не гуглу!)? Виртуализация уже много лет как есть. И даже бесплатная умеет больше докера. Про VMWARE молчу.
>(она ему и не нужна)
Конечно, у девопусов же мантра «быстро поднятое упавшим не считается» :)))
И от собственного микросерия головного мозга они не страдают. Хотя микросервисы понятие из лохматых 90-х и никто не мешал их делать последние 50 лет на любой из технологий (которые заметно легче очередного хайпового REST).
sn00p
Я предлагаю вам пойти еще дальше. Зачем нужна виртуализация, если все можно запускать в bare metal? Зачем вообще что-то нужно, если вы этого не понимаете?
Что плохого в том, что «быстро поднятое упавшим не считается»?
Вы читали вообще про 12-factor-app?
mspaint
>Вы читали вообще про 12-factor-app?
Ой, ну всё, до 2011 года программирования не было. И надежных сервисов.
С этим тоже смешно получается, есть такая очередная хайповая придумка маздайсофта — SDL. При этом, качество ХР и качество «дисяточки» почему-то не в пользу последней. А почему? Потому что «индусы заполонили» и «быстро поднятое упавшим не считается».
sn00p
Да конечно были, только сейчас 2019 год, количество информации в единицу времени растет по экспоненте. Старые подходы и старые технологии уже не работают, придумывают новые. Нормальный процесс, разве нет? Как вы будете, например, 10 гигабит данных в секунду обрабатывать, скриптом на перле? 3 года писать надежный сервис для этого? Ну, успехов чо
mspaint
Ну запустишь перл-скритп в докере и что изменится?
Cчитать, что без докера масштабируемость не делается — свою отсталость светить.
>10 гигабит данных в секунду обрабатывать
>3 года писать надежный сервис для этого
У фанатиков докера уже сам докер данные обрабатывает? Хехе… Ну, взяли докер, потом что, надежный сервис сам напишется? :)))
sn00p
Нет, я запущу кубернетес кластер, например, и там буду делать map-reduce, например, с использованием по максимуму всех возможностей kubernetes, автоматическое скалирование, например.
Что даст мне возможность сконцентрироваться на задаче обработки данных, за которую мне в итоге и платят. А задачи масштабирования, скалирования, HA и прочего с разработчиков будут сняты по максимуму. При этом разработчики будут коммитить по сто раз на день, а не раз в полгода. С моментальной выкладкой кода на прод, а не раз в полгода, на что будeт автоматически запускаться куча тестов, уменьшая в итоге количество ошибок и увеличивая качество продукта.
Что увеличивает эффективность, уменьшает косты и позволяет в итоге зарабатывать больше, а тратить меньше.
Merkat0r
Ох уж эти влажные мечты ;)
sn00p
Так вы попробуйте, может и у вас получится.
Мы к марту доделаем четвертый проект уже за год по похожей схеме. Kubernetes+JenkinsX+Gitlab, Hadoop
Приезжайте в мае на kubecon, я вам расскажу в деталях, без проблем.
mspaint
>Нет, я запущу кубернетес кластер, например, и там буду делать map-reduce, например, с использованием по максимуму всех возможностей kubernetes, автоматическое скалирование, например
Я забыл что на хабре каждый второй — архитектор фейспука, каждый первый
силиконовыйиз кремниевой долины. Не буду больше тебе мешать парсить гигабайт котиков в секунду. Всё, ты победил. Других инструментов для HA и MR не существует. Харе докер, харе кубернетис!p.s. «к марту доделаем четвертый проект»
и в 4-й раз в кусты? :))))
sn00p
Я не знаю, где вы там сидите в каких кустах, меня всегда можно найти на гитхабе, в чате кубернетса в слаке и на разного рода конференциях. Бывали хоть на одной? Приезжайте в мае на kubecon, например.
alex_blank
> Та же сетевая латентность при работе через докер выше.
Не выше, если использовать host network режим.
gecube
О, докеросрачик.
По host mode режиму — у меня строгое ощущение, что он создаёт больше проблем, чем решает. Ну, попробуйте в нем, например, запустить два postgres из одного образа. :) Понятно, что удариться в микроменеджмент и руками раскидывать все порты, но это убивает все преимущества docker.
Если у Вас другие ощущения — расскажите, прям даже интересно
Scf
Я считаю, что docker networking — зло. связывание локальных контейнеров в общую подсеть — фича сомнительной полезности, т.к. в реальной среде разные приложения обычно развернуты на разных хостах. Микроменеджмент портов это ни разу не отменяет, т.к. настраивать их или пробрасывать их — и там, и там нужна похожая конфигурация.
Мы строим работу с сетью примерно так:
Таким образом, всё работает быстро, слушающие порты настраиваются в конфиге приложения (мы ведем табличку портов для приложений, чтобы не было конфликтов, но порты можно назначать и рандомно), клиенты получают номер порта из service discovery.
powerman
docker networking удобен в случае, например, фрилансера, держащего на своей рабочей станции несколько не связанных проектов, которые хочется как-то изолировать друг от друга.
gecube
может все-таки стоит использовать vagrant?
По крайней мере присмотреться к нему поплотнее?
Ну, и я не поверю, что все эти «несколько несвязанных проектов» нужно держать запущенными одновременно, а не последовательно (хотя, конечно, кейсы разные бывают...)
Scf
ну, это частный случай. и даже в такой ситуации я предпочитаю написать простые шелл скрипты, поднимающие и опускающие нужный набор контейнеров.
arheops
Ну а телефония в докере показывает иногда и 20%+ падение производительности и проблемы со звуком.
С базой тоже есть патерны, показывающие падения(например, большое количество записи или не помещающиеся в память сеты).
sn00p
Как вы меряете производительность телефонии? Каждый пятый звонок обрабатывается неправильно и виноват прям докер? Да ладно.
С базой тоже непонятно, а без докера таких паттернов нет?
gecube
Производительность просто — речь о количестве клиентов или одновременно идущих (с минимально определенным качеством) телефонных разговоров.
Касательно базы — все же ясно.
и да, и нет. Просто докер вносит еще один уровень абстракции, еще один слой промежуточных сервисов, которые могут влиять на всю систему.
sn00p
То есть при запихивании абстрактного астериска в докер контейнер, количество обслуженных клиентов падает на 20 процентов? Это очень большая величина, почему так? Откуда 20% появилось? Как считали? Там просто неоткуда взяться такой цифре.
Ничего с базой неясно. Ютуб гоняет и ничо, жужжит вроде.
Ничего особого докер никуда не вносит, использует cgroups и немного сетевой магии. Кубернетес уже везде. Оверхед 5%, плюсов больше. Никакой еще один слой абстракции никуда не вносится, все механизмы давно в ядре. Слой промежуточных сервисов может влиять на всю систему, согласен. А может и не влиять, тут уж как настроишь.
arheops
Это число сказал я.
Зачем вы у него спрашиваете.
Считали так — запускаем нагрузочное тестирование и сложный диалплан с докером и без, увеличиваем нагрузку, пока не просядет качество.
У докера, lxc и openvz +- одинаковые показатели в данном тесте. У xen и qemu еще все хуже. Хуже всего дело обстоит у hyper-V.
sn00p
Ну, вы уверены, что вы там все правильно настроили и понимаете, что вы там тестили?
Я вот не уверен. В этих тестах, например, помешаны в кучу кони и люди. Вот Оpenvz, например, на каком ядре работает сейчас? 2.6.32? Даже со всеми патчами — это по-прежнему 2.6.32, с того времени сколько сотен тысяч строк в ядро накоммитили? Докер и lxc — это тоже немного разные вещи. Гипервизоры сюда еще как-то попали.
gecube
Я соглашусь, что измерение могло быть однобоким в том плане, что были выбраны неоптимальные и странные настройки докера. Другой вопрос, что почему эти странные и неоптимальные настройки были по дефолту. Например, мне руками приходилось драйвер менять на overlay2. Надеюсь, не будете отрицать, что aufs — сейчас это дно? Медленное.
sn00p
Тому причин множество. Overlay, например, не Posix Compliant, что может повлечь некоторые проблемы в работе приложений.
gecube
Примеры приведете? Или это чистая теория?
У меня именно из-за этого проблем не было, но это не означает, что это их не может вызвать в принципе
sn00p
docs.docker.com/storage/storagedriver/overlayfs-driver/#limitations-on-overlayfs-compatibility
Scf
неужели вы пишете в контейнер? так не надо делать, рабочие каталоги должны быть смапплены наружу.
gecube
Я не пишу, но в контейнере может быть что угодно.
Например, пишутся неотключаемые логи или временные файлы.
Или мне безразлична судьба базы данных.
Что тогда скажете?
Понятно, что не все кейсы должны случаться
Хотя бы из каких-то разумных соображений.
Но чисто гипотетически в качестве образа Вам могут передать что угодно. И с неверной инструкцией.
Для справедливости скажу, что, вот, например, постгресовский дефолтных образ базу ВСЕГДА пишет в вольюм. Независимо от Вашего желания. Потому что объявлен в Dockerfile. Т.е. если явно ничего не делать, то появляются безымянные вольюмы, но, в общем-то, это не особо страшно. И это даже хорошо
sn00p
Кто вам мешает пересобрать и сделать правильно?
arheops
Количество звонков, при котором вы гарантировнно получаете проблемы со звуком = производительность телефонии. Если ставил эксперт, то процентов на 20 разница. Там очень много мелких пакетов проходит(mpps). А вообще может и со старта быть проблемы со звуком.
Производительность базы похоже на падение как с недавним мелдаун патчем. Когда у вас быстрая ssd и много операций чтения — это заметно. Естественно вы это не заметите на супер-медленных hdd.
В общем не стоит виртуализацию сунуть там, где она не нужна.
sn00p
Да, только докер — это не виртуализация. Диски тут вообще никак не аффектятся.
Медленнее в докере только сеть.
«An Updated Performance Comparison of Virtual Machines and Linux Containers» by Felter et al. that provides a comparison between bare metal, KVM, and Docker containers. The general result is that Docker is nearly identical to Native performance and faster than KVM in every category.
Докер — это система изоляции, никакого оверхеда там почти нет. Тем более не может быть никаких 20%, 57 тысяч человек в слак чате кубернетеса подтвердят.
arheops
Да ладно. Даже LVM это виртуализация в том или ином виде. Докер контейнеры это лишние проверки на пути.
Конечно, это виртулизация. Просто не PVM.
gecube
Да чего говорить с докер-зомби — только бисер метать…
Вот что бывает при фанатичном использовании технологий… А мудрость… Ну, появится потом…
sn00p
Так не надо метать бисер, приведите факты. Пока я вижу только некие «20%», некие «лишние проверки» и прочее. При этом ютуб-то работает?
gecube
Мне очень жаль, что Вы не понимаете разницы между latency & throughput/bandwidth. В орфографии мог немного ошибиться )
Обслуживая массового клиента мы в первую очередь стараемся охватить бОльшее количество клиентов, чем сделать сервис отзывчивым для каждого из них. В общем-то это в струе docker'а. Он, к сожалению, не про скорость, а больше про скорость разработки, вывода в продакшн, про изоляцию и про унификацию среды.
sn00p
Да с чего не про скорость, я выше приводил цитату, где уже все померяли и замерили еще в 2012 году.
«An Updated Performance Comparison of Virtual Machines and Linux Containers» by Felter et al. that provides a comparison between bare metal, KVM, and Docker containers. The general result is that Docker is nearly identical to Native performance and faster than KVM in every category."
gecube
Да сравнение там некорректное. Не на всех типах нагрузки. К тому же много воды с тех пор утекло.
Краткий вывод получается, что при сравнении производительности kvm vs docker — докер всегда рвет КВМ (ну, прям К.О.), т.к. он все-таки контейнеризация, а не виртуализация. Касательно docker vs bare-metal даже из того обзора видно, что сеть немного, но медленнее, да и диск гоняли только в одном из режимов. У меня цели жонглировать цифрами и фактами нет, но могу сказать, что в реальности картина немного другая. Да и учтите, что обычно докеры крутят на ВМках… А не поверх баре-метала. Что вносит еще больше неизвестных.
selenite
ага, при условии, что те же bind mount'ы выставлены так, что /var и /tmp контейнера смотрят на тот же диск, где data volume'ы/mount'ы.
иначе получается, что какой-нибудь перегон пары гигабайт временных данных происходит не на уровне фс, а на уровне блочных устройств, «незаметно» для юзера отжирая время и ресурсы
sn00p
Да, выразился неверно. Это виртуализация, на уровне операционной системы, в рамках одной ОС. Лишние проверки на пути — проверки чего? Вместо одного экземпляра пространства пользователя, работает несколько, акей. Как это влияет на количество каких-то проверок?
gecube
На пути системных вызовов. Например, очевидно, что доступ к файлу на слоеной файловой системе должен пройти через все слои в худшем случае. Действительно, скорость может не сильно пострадать. Да и задержка тоже. Но могут быть специфические кейсы, в которых просадка будет заметна.
Или Вы утверждаете, что это будет быстрее, чем обратиться к файлу на настоящей ФС?
sn00p
Все зависит от настроек. Может вы там лупбек тестили на лвм. Тогда будет медленнее. Overlay2 будет даже быстрее.
А зачем файловую систему вообще тестить в докере? Для этого есть персистентные хранилища, контейнер сам по себе эфемерная сущность.
gecube
А Вы правда думаете, что ее скорость не играет роли от слова совсем?
sn00p
Скорость чего? Файловой системы эфемерного докера или файловой системы персистентного хранилища? Вы вообще понимаете, как устроен и как работает докер?
Merkat0r
Тяжелый случай…
Scf
да, не влияет. ФС в докере нужна исключительно для чтения бинарников в память. всё серьезное IO должно быть смапплено на каталоги основной файловой системы.
norguhtar
Это не виртуализация ни разу. Это банальное увеличение изоляции. Ядро остается одно на всех и виртуализации устройств не происходит.
Arris
Да без разницы, что модно. Главное — чтобы работало, а не было модным.
Ну, если вам конечно не надо меряться понтами с другими айтишниками.
norguhtar
Там все так же плохо. Для каждого сервиса пишется свой скрипт. У systemd из ключевых моментов про который редко кто говорит, это отсутствие привязки к какому-то sh в описании сервиса. Он там просто не требуется. В итоге в случае если у вас ПО запускается на разных дистрибутивах то можно использовать один и тот же unit файл. В итоге для linux к примеру разработчик может включать unit файл для своего ПО и будет уверен, что он работает. В отличии от пачки init скриптов которые обычно для ПО писались непосредственно мантейнерами дистрибутива.
TonyLorencio
Вот только документацию
всеммногим читать лень, и одни и те же (далеко не идеальные) копипастные шаблоны гуляют от сервиса к сервису.(Справедливо как для systemd unit'ов, так и для init-скриптов.)
norguhtar
Для systemd это меньшая трагедия, практически все unit там малы и понятны :)
arheops
Это пока малы
gecube
Они и не рассчитаны на то, чтобы быть монструозными. И сложность переходит на уровень взаимодействия юнитов друг с другом, а не нарастает ВНУТРИ юнитов.
arheops
Возможно вы не помните, но тоже говорили про init.d/rc.d
Ничего не мешает индийским кодерам насунуть внутрь больше ctr-v
Gutt
Всё же описание сервиса — не скрипт, а скорее декларация. В любом случае, простой сервис определяется за пять минут, отладки практически не требует. После SysV init — глоток свежего воздуха, честное слово.
norguhtar
Именно так. Более того, в тех же redhat и debian в sysvinit это частично пытались втаскивать через конфигурации с стандартные скрипты. Но это все равно совсем не то.
maisvendoo
Я соглашусь с Вами в одном моменте, который, с точки зрения моей (не админа, а продвинутого юзера-разработчика, использующего линукс в своей деятельности)
Вот! Эта подсистема инициализации покрывает 90% популярных дистрибутивов, и, при всех недостатках (о которых я не берусь судить ни в коей мере!) стала стандартом дэ-факто. А значит разобраться в работе навскидку взятой системы, починить её и настроить стало проще, потому что нужно знать только одну подсистему инициализации.
Другой вопрос, что при несовершенстве стандарта его нужно улучшать. Но я, как просто потребитель продукта GNU/Linux оцениваю шествие systemd по планете больше положительно, чем отрицательно.
никто не лишал нас выбора — очень многие мои арчеколлеги юзают OpenRC и не жалуются. К счастью линук != отсутствие выбора, при должном уровне квалификации, разумеется
gecube
Арч и прочие — это весьма маргинальные дистрибутивы, которыми пользуются, ну, наверное, процентов 10 максимум. Я говорю именно про сервера, а не персональные машинки. К сожалению, у меня на руках нет точных цифр, т.к. я не нашел правильных обзоров. Но, повторюсь, что по ощущениям топчик такой: ubuntu, centos/rhel, debian, потом уже все остальное.
maisvendoo
Называть арчеводов маргиналами… ну, как-то грубовато, не находите? Тем не менее да, арчеводов довольно мало, но systemd не только на арче, а и на всём перечисленном Вами, и альтернативные подсистемы инициализации доступны и там.
gecube
Да, прошу прощения, я не про то, чтобы обидеть, а про то, что это меньшинства.
maisvendoo
Я понял, ничего страшного)
dartraiden
На первый взгляд, по большей части там приводятся аргументы, опровергаемые Райсом.
powerman
Это не совсем так, вчитайтесь чуть внимательнее. Там описана базовая проблема (с точки зрения автора) дизайна systemd:
Всё остальное — это просто логичные следствия этого подхода, среди которых действительно встречаются и упомянутые Райсом.
pal666
автор этого опуса, мягко говоря, не в теме. sytemd это linux basesystem. т.е. вместо стенаний «BSD is not dead, Solaris is not dead, but systemd ignores Unix» можно пройти и посмотреть, из чего состоит и как разрабатывается freebsd base
norguhtar
Ну и там вопросы, а почему кто-то должен поддерживать FreeBSD и прочее? Им надо пусть поддерживают. Никто не мешает патчи писать, если патчи не принимают форкнуть в конце концов. Или написать свой который реально лучше.