Comments 330
Попахивает Стокгольмским синдромом. Адекватно и корректно про трагедию systemd написано здесь: https://www.skarnet.org/software/s6/systemd.html (англ.).
Кошмар с init.d для меня ушёл в прошлое в 2001 году, когда я собрал свой дистрибутив на базе LFS с запуском сервисов через daemontools. Правда, появился кошмар поддержки своего дистрибутива, но это решилось переходом в 2004 на Gentoo с использованием runit и в качестве init и для управления сервисами. 15 лет такой вариант Gentoo используется и на рабочих станциях и на серверах — никаких проблем нет, всё работает крайне надёжно и требует минимальной поддержки раз в пару лет (я про конфиги runit для загрузки ОС и/или сервисов).
Что касается запуска собственных проектов где-нить на AWS, то там запускается любой дистрибутив, под него ставится докер, и всё остальное происходит исключительно в докере — что там за дистрибутив на хосте и используется ли в нём systemd или что-то другое — уже без разницы, на хосте помимо установки докера разве что специфичным для дистрибутива способом запускаются обновления ОС.
Предлагаете все тащить в докер? И БД (монга, постгрес и пр.) тоже?
И если уж на то пошло:
- тогда дистрибутивы типа Gentoo, Centos и пр. не нужны — лучше брать CoreOS Container Linux
- compute instance вообще не нужны — нужна платформа типа кубернетеса.
И, да, докер — это уже прошлый день. Теперь модно CRI-O/containerd.
Да без разницы, какой дистрибутив, и без разницы, докер или что-то другое модное, суть в том, что то, что мы раньше ставили на сервера системными сервисами теперь ставится контейнерами. БД в докере работает ничуть не хуже, чем вне докера — volume с данными по сути подключается через bind mount каталога хоста, так что проседания производительности нет.
Сам проводил измерения. Но есть нюансы ) дьявол в деталях.
Та же сетевая латентность при работе через докер выше. Для какого-нибудь хостинга или простого сайта это некритично, но для серьезных применений — так себе и нужно это учитывать.
С другой стороны — действительно, systemd позволяет все настроить так же. И даже зарезать сервисы по cpu/mem через те же cgroups. Нужно ли в этот зоопарк тащить ещё и докер, т.е. лишнюю сущность — ну, пускай решает сам )))
P.s. я уж не говорю какой это ад настроить файрволл на машине с докер-демоном, под управлением scm, да ещё и в роли vpn пира )))
Ну, я бы не сказал, что прямо ад. У меня на домашнем сервере 20 сетевых интерфейсов, часть разные локалки для изоляции, пара провайдеров, несколько клиентов openvpn, сервер openvpn, ну и докер (причём в нём несколько разных проектов, каждый в своей docker network) — настройки iptables у меня ручные, довольно сложные, но про докер там почти ничего — прописаны его подсети для антиспуфинга и немного фильтрации. Докер в iptables сам кучу своего добавляет, но этими правилами он рулит сам, и пока они ничего не ломали, хотя в моих условиях этого можно было ожидать.
А на нормальных серверах я обычно все докеры помещаю в общую сеть площадки (staging, prod, etc.), не доступную напрямую из инета, и файрвол настраиваю на сервере-шлюзе между этой сетью и инетом (ну и плюс в роли а-ля файрвола по конкретным докер-сервисам выступает конфиг nginx куда приходят запросы юзеров, фактически этот конфиг определяет, какие докер-сервисы публичные, а какие нет).
Что касается латентности — да, но это для абсолютного большинства проектов некритичный недостаток, зато бонусов от упаковки конкретных версий сервисов в образы докера и запуска их везде — от CI до машин разработчиков — намного больше.
В целом — преимущества от использования докера перевешивают недостатки и сложности, вносимые им. Но, к сожалению, мои разработчики вот эти вот граничные кейсы вряд ли осилят сами.
Есть несколько идей как такое победить. Например, можно определить структуру контейнеров изначально. Администратор ее формирует, а далее через sudoers даёт возможность выполнять команды docker пользователям только над своими контейнерами. Или, я тут позавчера случайно узнал, можно запустить два докер демона. Не изучал глубоко эту возможность, но для чего-то это может пригодиться.
Но лучше решение, конечно, — наверное, мигрировать в кубернетес или опеншифт. Он большой пласт этих вопросов закрывает
Конечно, последним рубежом является выделение одного и более виртуального сервера на проект…
Понятно, что можно отрезать все ручки, чтобы все было только автоматизированно. А на сервере пускать только по служебкам… Но это такое себе…
Конечно, последним рубежом является выделение одного и более виртуального сервера на проект…
несомненно. Это еще и другие плюсы — например, удобнее считать косты, чем пытаться понять какая загрузка сервера в этом месяце была между проектами, если они его делят.
Попробуйте повоевать с дата-сатанистами на этот счет )))
Безопасность практически всегда вредит удобству использования, но я полностью согласен с alexkuzko — деплой на сервера необходимо автоматизировать через CI/CD, доступ на сервера должен быть только у devops, разработчики, даже если они дата-сатанисты, должны вносить все изменения в код только через репо (причём право мержа в ветку, которая автоматом выкатывается на сервер, должно быть только у тимлида) и непосредственного доступа к докеру не иметь.
Либо, если это не прод, то можно поднять им отдельный сервер и дать полный доступ к нему, главное чтобы была возможность быстро грохнуть его и пересоздать с нуля за несколько минут, на случай его они его сломают.
Либо, если это не прод, то можно поднять им отдельный сервер и дать полный доступ к нему, главное чтобы была возможность быстро грохнуть его и пересоздать с нуля за несколько минут, на случай его они его сломают.
ну, или откатить состояние, если уж на то пошло.
Ну, дома я действительно вынужден либо перезапускать докер после перегрузки правил iptables, либо менять правила по одному и ручками, не забывая при этом продублировать их в системный конфиг чтобы они сохранились после перезагрузки. А на серверах, как я уже говорил, проблема решается отсутствием отдельных правил iptables на серверах с докером, они настраиваются на шлюзе и/или в AWS VPC.
>Ну, я бы не сказал, что прямо ад.
Для типичного девопуса добавить правило после докера — непосильная задача. И сам докер писали, похоже, такие же девопусы — например очень типичное правило в таблице nat делающее redirect с 8080 по 80 порт докер не видит и просто тупо не работает. А типичный девопус сидит целый день над этой страшной проблемой и чешет голову, Я и Ж.
>зато бонусов от упаковки конкретных версий сервисов в образы докера и запуска их везде
Да, девопуса заставить обновлять что-либо невозможно. Даже если их сильно пинать за устаревший софт. Иначе бы пользовались yum-репозиториями вендора.
Мне вообще удивительно, как инструменты нищебродного хайлоада (т.е. когда нагрузок много, а денег мало) расползаются и в нормальное ИТ.
До докера уже много лет можно было делать live migration. С «могучим» докером это проблема. Софт писали так, чтобы он не падал раз в день, соответственно 100500 копий его запускать смысла не было. Вменяемое количество копий и деплой по группам можно делать средствами application server-а уже 15 лет. Журналы (логи) читали. А сейчас модно запустить 100500 копий, 30% из которых возможно как-то худо-бедно будут работать, потом терабайты логов грузить в специально развернутый очередной кластер и НЕ ЧИТАТЬ. И этот подход впаривают как передовой… (рукалицо)
Для типичного девопуса добавить правило после докера — непосильная задача. И сам докер писали, похоже, такие же девопусы — например очень типичное правило в таблице nat делающее redirect с 8080 по 80 порт докер не видит и просто тупо не работает. А типичный девопус сидит целый день над этой страшной проблемой и чешет голову, Я и Ж.
Проблема не в том, что это непосильная задача, а проблема в том, что это сложности на ровном месте. Вы же понимаете, что правило из таблицы NAT имеет приоритет перед таблицей filter со всеми вытекающими. А еще отдельная история, когда правило в nat есть, в filter разрешающего нет и ты удивляешься почему контейнер одним способом доступен, а по прямому IP хоста — нет.
И только вот в каких-то последних версиях докера сделали наконец-то отдельные цепочки DOCKER-USER, хотя, честно говоря, не особо это и спасает.
Софт писали так, чтобы он не падал раз в день, соответственно 100500 копий его запускать смысла не было.
это последствия тренда на то, что мы все запускаем на дешевом голимом ненадежном железе, потому что массовый рынок, а реально надежные и хорошие железки выдавливаются в очень узкий сегмент. Но производитель же ведь тоже не дурак и хочет кушать ) и поэтому наценка на эти узкоспециализированные, но очень надежные железки взлетает в космос (это типичная экономическая история). Касательно надежности еще момент, что всегда что-то может отказать. Независимо от количества девяток. И нужно иметь план Б. Будь-то восстановление с простоем, или что проще — иметь реплику и переключать на нее трафик.
Мы это кто конкретно? :) Я в прошлом сообщении уже проехался по нищебродно-хайлоадному подходу. Гугл, вроде, на коньсюмерном мусоре раньше крутился. Зачем натягивать сову на глобус (инструменты для решения проблем масштабирования гугла втюхивать всем)?
В нормальных конторах, даже не особо богатых, в стойках стоят серверы, с надежностью оных ничего не случилось. Сейчас наоборот виртуализация используется в 90% случаев, которая умеет live migration. А докер?!
И касательно железа, я наоборот не устаю поражаться — даже в плохих условиях (регулярные сбои системы охлаждения, а серверы работают как часы. Даже после многократных самоотключений по достижении +42С ambient. ;) У дисков SMART смотришь — 55-57 градусов. И живут по 7 лет. И тд и тп.
И касательно железа, я наоборот не устаю поражаться — даже в плохих условиях (регулярные сбои системы охлаждения, а серверы работают как часы. Даже после многократных самоотключений по достижении +42С ambient. ;) У дисков SMART смотришь — 55-57 градусов. И живут по 7 лет. И тд и тп.
а) были исследования, которые показывают, что с ростом температуры количество отказов нарастает. Например, желтизна, но повод подумать.
б) есть куча историй про вылеты дисков. От перегрева тоже. И из «бракованных» (нет, мне не нравится, давайте назовем лучше — рискованных или ненадежных) серий и партий
в) у гугла были проблемы с отказами в ДЦ из-за перегрева. Из новостей нашел аналогичную историю про MS тыц.
г) по поводу железа — действительно нужно удивляться, что оно вообще работает. Это такая сложная инженерная материя ))) что прямо магия. И не нужно питать иллюзий по поводу надежности.
В нормальных конторах, даже не особо богатых, в стойках стоят серверы, с надежностью оных ничего не случилось. Сейчас наоборот виртуализация используется в 90% случаев, которая умеет live migration. А докер?!
так виртуализация за эти и нужна, чтобы тоже компенсировать недостаток надежности железа + более гибкое управление ресурсами.
Докер — лив-миграцию сам не умеет (она ему и не нужна), но со всякими обвязками отчасти решает проблему.
Я в прошлом сообщении уже проехался по нищебродно-хайлоадному подходу.
и что? Мы живем в рамках некой парадигмы. И если все делают каким-то образом, то и нам тоже придется делать так же. Экономика-с.
Мы это кто конкретно?
Мы — все. Ну, может кроме каких-то специфичных применений из mission critical, но там есть соответствующие бюджеты.
>Докер — лив-миграцию сам не умеет
Итого, спрашивается, а зачем нужен докер (не гуглу!)? Виртуализация уже много лет как есть. И даже бесплатная умеет больше докера. Про VMWARE молчу.
>(она ему и не нужна)
Конечно, у девопусов же мантра «быстро поднятое упавшим не считается» :)))
И от собственного микросерия головного мозга они не страдают. Хотя микросервисы понятие из лохматых 90-х и никто не мешал их делать последние 50 лет на любой из технологий (которые заметно легче очередного хайпового REST).
Что плохого в том, что «быстро поднятое упавшим не считается»?
Вы читали вообще про 12-factor-app?
Ой, ну всё, до 2011 года программирования не было. И надежных сервисов.
С этим тоже смешно получается, есть такая очередная хайповая придумка маздайсофта — SDL. При этом, качество ХР и качество «дисяточки» почему-то не в пользу последней. А почему? Потому что «индусы заполонили» и «быстро поднятое упавшим не считается».
Cчитать, что без докера масштабируемость не делается — свою отсталость светить.
>10 гигабит данных в секунду обрабатывать
>3 года писать надежный сервис для этого
У фанатиков докера уже сам докер данные обрабатывает? Хехе… Ну, взяли докер, потом что, надежный сервис сам напишется? :)))
Что даст мне возможность сконцентрироваться на задаче обработки данных, за которую мне в итоге и платят. А задачи масштабирования, скалирования, HA и прочего с разработчиков будут сняты по максимуму. При этом разработчики будут коммитить по сто раз на день, а не раз в полгода. С моментальной выкладкой кода на прод, а не раз в полгода, на что будeт автоматически запускаться куча тестов, уменьшая в итоге количество ошибок и увеличивая качество продукта.
Что увеличивает эффективность, уменьшает косты и позволяет в итоге зарабатывать больше, а тратить меньше.
> Та же сетевая латентность при работе через докер выше.
Не выше, если использовать host network режим.
По host mode режиму — у меня строгое ощущение, что он создаёт больше проблем, чем решает. Ну, попробуйте в нем, например, запустить два postgres из одного образа. :) Понятно, что удариться в микроменеджмент и руками раскидывать все порты, но это убивает все преимущества docker.
Если у Вас другие ощущения — расскажите, прям даже интересно
Я считаю, что docker networking — зло. связывание локальных контейнеров в общую подсеть — фича сомнительной полезности, т.к. в реальной среде разные приложения обычно развернуты на разных хостах. Микроменеджмент портов это ни разу не отменяет, т.к. настраивать их или пробрасывать их — и там, и там нужна похожая конфигурация.
Мы строим работу с сетью примерно так:
- все наши образы позволяют настраивать номер порта и интерфейс для всех слушающих портов.
- если сервис нужен только локально, он биндится на локалхост
- имя сервиса-ip-порт сохраняются в service discovery
Таким образом, всё работает быстро, слушающие порты настраиваются в конфиге приложения (мы ведем табличку портов для приложений, чтобы не было конфликтов, но порты можно назначать и рандомно), клиенты получают номер порта из service discovery.
docker networking удобен в случае, например, фрилансера, держащего на своей рабочей станции несколько не связанных проектов, которые хочется как-то изолировать друг от друга.
По крайней мере присмотреться к нему поплотнее?
Ну, и я не поверю, что все эти «несколько несвязанных проектов» нужно держать запущенными одновременно, а не последовательно (хотя, конечно, кейсы разные бывают...)
ну, это частный случай. и даже в такой ситуации я предпочитаю написать простые шелл скрипты, поднимающие и опускающие нужный набор контейнеров.
С базой тоже есть патерны, показывающие падения(например, большое количество записи или не помещающиеся в память сеты).
С базой тоже непонятно, а без докера таких паттернов нет?
Касательно базы — все же ясно.
а без докера таких паттернов нет?
и да, и нет. Просто докер вносит еще один уровень абстракции, еще один слой промежуточных сервисов, которые могут влиять на всю систему.
Ничего с базой неясно. Ютуб гоняет и ничо, жужжит вроде.
Ничего особого докер никуда не вносит, использует cgroups и немного сетевой магии. Кубернетес уже везде. Оверхед 5%, плюсов больше. Никакой еще один слой абстракции никуда не вносится, все механизмы давно в ядре. Слой промежуточных сервисов может влиять на всю систему, согласен. А может и не влиять, тут уж как настроишь.
Зачем вы у него спрашиваете.
Считали так — запускаем нагрузочное тестирование и сложный диалплан с докером и без, увеличиваем нагрузку, пока не просядет качество.
У докера, lxc и openvz +- одинаковые показатели в данном тесте. У xen и qemu еще все хуже. Хуже всего дело обстоит у hyper-V.
Я вот не уверен. В этих тестах, например, помешаны в кучу кони и люди. Вот Оpenvz, например, на каком ядре работает сейчас? 2.6.32? Даже со всеми патчами — это по-прежнему 2.6.32, с того времени сколько сотен тысяч строк в ядро накоммитили? Докер и lxc — это тоже немного разные вещи. Гипервизоры сюда еще как-то попали.
неужели вы пишете в контейнер? так не надо делать, рабочие каталоги должны быть смапплены наружу.
Например, пишутся неотключаемые логи или временные файлы.
Или мне безразлична судьба базы данных.
Что тогда скажете?
Понятно, что не все кейсы должны случаться
Хотя бы из каких-то разумных соображений.
Но чисто гипотетически в качестве образа Вам могут передать что угодно. И с неверной инструкцией.
Для справедливости скажу, что, вот, например, постгресовский дефолтных образ базу ВСЕГДА пишет в вольюм. Независимо от Вашего желания. Потому что объявлен в Dockerfile. Т.е. если явно ничего не делать, то появляются безымянные вольюмы, но, в общем-то, это не особо страшно. И это даже хорошо
Производительность базы похоже на падение как с недавним мелдаун патчем. Когда у вас быстрая ssd и много операций чтения — это заметно. Естественно вы это не заметите на супер-медленных hdd.
В общем не стоит виртуализацию сунуть там, где она не нужна.
Медленнее в докере только сеть.
«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 тысяч человек в слак чате кубернетеса подтвердят.
Конечно, это виртулизация. Просто не PVM.
Вот что бывает при фанатичном использовании технологий… А мудрость… Ну, появится потом…
Обслуживая массового клиента мы в первую очередь стараемся охватить бОльшее количество клиентов, чем сделать сервис отзывчивым для каждого из них. В общем-то это в струе docker'а. Он, к сожалению, не про скорость, а больше про скорость разработки, вывода в продакшн, про изоляцию и про унификацию среды.
«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."
Краткий вывод получается, что при сравнении производительности kvm vs docker — докер всегда рвет КВМ (ну, прям К.О.), т.к. он все-таки контейнеризация, а не виртуализация. Касательно docker vs bare-metal даже из того обзора видно, что сеть немного, но медленнее, да и диск гоняли только в одном из режимов. У меня цели жонглировать цифрами и фактами нет, но могу сказать, что в реальности картина немного другая. Да и учтите, что обычно докеры крутят на ВМках… А не поверх баре-метала. Что вносит еще больше неизвестных.
иначе получается, что какой-нибудь перегон пары гигабайт временных данных происходит не на уровне фс, а на уровне блочных устройств, «незаметно» для юзера отжирая время и ресурсы
Или Вы утверждаете, что это будет быстрее, чем обратиться к файлу на настоящей ФС?
А зачем файловую систему вообще тестить в докере? Для этого есть персистентные хранилища, контейнер сам по себе эфемерная сущность.
А зачем файловую систему вообще тестить в докере?
А Вы правда думаете, что ее скорость не играет роли от слова совсем?
да, не влияет. ФС в докере нужна исключительно для чтения бинарников в память. всё серьезное IO должно быть смапплено на каталоги основной файловой системы.
Ну, если вам конечно не надо меряться понтами с другими айтишниками.
Вот только документацию всем многим читать лень, и одни и те же (далеко не идеальные) копипастные шаблоны гуляют от сервиса к сервису.
(Справедливо как для systemd unit'ов, так и для init-скриптов.)
systemd есть уже везде
Вот! Эта подсистема инициализации покрывает 90% популярных дистрибутивов, и, при всех недостатках (о которых я не берусь судить ни в коей мере!) стала стандартом дэ-факто. А значит разобраться в работе навскидку взятой системы, починить её и настроить стало проще, потому что нужно знать только одну подсистему инициализации.
Другой вопрос, что при несовершенстве стандарта его нужно улучшать. Но я, как просто потребитель продукта GNU/Linux оцениваю шествие systemd по планете больше положительно, чем отрицательно.
что по сути хоть нас и лишили выбора
никто не лишал нас выбора — очень многие мои арчеколлеги юзают OpenRC и не жалуются. К счастью линук != отсутствие выбора, при должном уровне квалификации, разумеется
Арч и прочие — это весьма маргинальные дистрибутивы, которыми пользуются, ну, наверное, процентов 10 максимум. Я говорю именно про сервера, а не персональные машинки. К сожалению, у меня на руках нет точных цифр, т.к. я не нашел правильных обзоров. Но, повторюсь, что по ощущениям топчик такой: ubuntu, centos/rhel, debian, потом уже все остальное.
Арч и прочие — это весьма маргинальные дистрибутивы, которыми пользуются, ну, наверное, процентов 10 максимум
Называть арчеводов маргиналами… ну, как-то грубовато, не находите? Тем не менее да, арчеводов довольно мало, но systemd не только на арче, а и на всём перечисленном Вами, и альтернативные подсистемы инициализации доступны и там.
Это не совсем так, вчитайтесь чуть внимательнее. Там описана базовая проблема (с точки зрения автора) дизайна systemd:
The single, overarching problem with systemd is that it attempts, in every possible way, to do more instead of less.
Всё остальное — это просто логичные следствия этого подхода, среди которых действительно встречаются и упомянутые Райсом.
Например, контрольные группы — высокоэффективный и интересный механизм управления процессами, без них было бы гораздо труднее решать эти задачи. Они гораздо более мощные и детальные, чем джейлы FreeBSD.
Странно разработчику FreeBSD сравнивать CGroups c jail. Насколько я знаю CGroups — это метод управления разделением ресурсов системы между группами процессов. С Jail скорее соотносятся пространства имён. Да и чрезмерная навороченность cgoups не позволяет ими пользоваться в отрыве от такого инструмента как systemd, поскольку управлять руками всеми этими параметрами нереально (а реально ли ими вообще управлять человеку? это всё помещается в одну голову?). В FreeBSD можно пользоваться учётом и ограничением ресурсов, причём вешать это ограничение именно на jail-ы объединяя группы процессов в контейнеры, что ИМХО намного прозрачнее управлением ресурсами по-сервисно.
у Райса для них простой ответ: «Unix мёртв». Когда-то Unix был упражнением в предельной переносимости и имел реальный успех. Но теперь мы живём «в мире Linux с небольшими ошибками округления»
Когда-то это мир принадлежал Microsoft Windows, и эти времена ещё не прошли до конца. Кроме того в самом Unix были лидеры отрасли, захватывающие поляну на время. ИМХО не стоит настолько ультимативно заявлять о безальтернативности Linux…
ИМХО не стоит настолько ультимативно заявлять о безальтернативности Linux…
мир очень изменяется. Раньше были и мейнфреймы, к которым одновременно подключались сотни пользователей. А завтра — все вычисления будут в облаке, поверх lambda / FaaS. И эти линуксы будут никому не нужны. Точнее не так — они будут обеспечивать работу всей этой махины, только знать их нужно будет именно тому персоналу, который обеспечивает этот промежуточный слой. А потребителю услуги (т.е. разработчику) будет предоставлена возможность писать код на более высоком уровне абстракции на его любимом языке.
Чур вас с облаками.
Они нужны для крайне малой категории задач и пускай там и остаются, в большинстве случаев они противопоказаны. Вычисления, если возможно, нужно производить ближе к пользователю.
Мощностей пользовательского оборудования сейчас более чем достаточно, особенно если избавиться от ненужных абстракций "любимого" языка программирования. Если пропускную способность с горем попалам поднимают(и далеко не бесплатно), то задержки сети и доступность ещё никому победить не удалось, не говоря уже о потери контроля за данными.
Kubernetes поверх «малинок» уже возможен и на одном из митапы его продавали. Но этого недостаточно, чтобы эту область вытянуть.
Kubernetes поверх «малинок» уже возможен и на одном из митапы его продавали.
А применение этому безобразию то какое? ну кроме отказоустойчивых микросервисов управления домом…
Что-то такого плана www.youtube.com/watch?v=1vTn9qs24Ug
Раньше были и мейнфреймы, к которым одновременно подключались сотни пользователей. А завтра — все вычисления будут в облаке, поверх lambda / FaaS
Ну то есть ничего не поменялось, кроме интерфейса доступа к Mainframe. Ведь если вычесть из стоимости этой железки всё ЧСВ её создателей и продвигателей на выходе останется решение с достаточно оптимальным соотношением отказоустойчивости, управляемости, энергопотребления… Проблема то этих машин только в запретительной цене закупки и поддержки.
Вот эта попытка менять весь мир под себя (есть мейнстримный Linux, а все остальные идут лесом) очень напоминает то, как себя вёл Microsoft cо своим Windows в своё время. В итоге игнорирование, или, в более мягкой формулировке — недостаточное внимание, ко мнению общественности пошло самому продукту во вред.
Собственно тот же процесс начался и на Linux, когда вследствие такого рода эгоцентричности страдать начинают сами пользователи системы. К примеру, чего стоит недавнее заявление о том что ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится.
UPD: Для ленивых — www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Workaround
Не знаю, что там у вас не будет собираться, потому что у меня всё собирается много лет начиная с FreeBSD 8.0 прямо с ядром.
Насчёт перспектив в Linux лучше почитать предыдущий тред вместе с комментариями.
https://www.phoronix.com/scan.php?page=news_item&px=ZFS-On-Linux-5.0-Problem
К примеру, чего стоит недавнее заявление о том что ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидится.
Просто обратите внимание на общую [для всего мира] тенденцию — не нужно потребителю знать, что там под капотом: закройте глаза и пользуйте. Сломалось — несите в СЕРВИС. Вот и в ИТ Вам будут продавать сервис: *aaS
Смириться. Пока тенденцию не качнёт обратно :)
P.S. потому на *tree-fs и строят всякие "лисапеты", вместо того, чтобы просто сделать zfs diff :))
Под фрей поломать zfs мне не удавалось, а вот под линуксом на не слишком интенсивном i/o, но зато на требовательных по памяти задачах — получил oom с kernel panic и потерю данных в разделе с zfs. Ну и, к тому же, отдавать до четверти памяти под рабочие структуры фс — иногда перебор, тут всё ж не сервер-хранилище, а запускалка приложений в виртуалке с единственным /dev/vda.
Сломалось — несите в СЕРВИС.
P.S. потому на *tree-fs и строят всякие «лисапеты», вместо того, чтобы просто сделать zfs diff
а какими глазами на вас посмотрит сервис, когда вы придете к нему со сломанным зфс диффом?
ядро 5.0 скорее всего не будет поддерживать ZFS при том, что ничего enterprise ready в замен там в ближайшие годы не предвидитсязол никогда не была и никогда не будет энтерпрайз реди. просто потому что энтерпрайз не совместим с неподдерживаемым tainted ядром. в то же время есть энтерпрайз дистры, в которых дефолтная файловая система бтрфс. которая ими поддерживается и у которой, в отличие от зфс(даже солярисовой, которая таки да энтерпрайз, а не неподдерживаемый костыль), не устаревший дизайн
зол никогда не была и никогда не будет энтерпрайз реди
Очень может быть что так. Однако, и альтернатив реальных пока нет.
BTRFS по многочисленным отзывам даже её поклонников, а также отказу от поддержки её развития со стороны "пингвинячьего всего" Redhat, находится на расстоянии лет (если не вечности) от стадии enterptise ready. Только на Oracle и надежда.
Несмотря на более современную архитектуру.
Трудно сказать что там творится под капотом, возможно у них там своя BTRFS с бэкджеком и шлюхами, но на средину прошлого года общедоступная BTRFS, по отзывам её поклонников, была глючным ломучим говном.
http://forum.ixbt.com/topic.cgi?id=109:309:9301#9301
Как storage driver для докера, претензий нет.
Как и ожидалось, в статье нет ни слова про daemontools, runit или Supervisor, но вместо этого — ложная дихотомия sysvinit vs systemd, и попытки преподнести любую критику как простое ретроградство.
Поклонники systemd, однако, такие поклонники.
Вот сравнение: https://www.skarnet.org/software/s6/why.html
Как и ожидалось, в статье нет ни слова про daemontools, runit или Supervisor, но вместо этого — ложная дихотомия sysvinit vs systemdэто легко объяснимо. раньше везде стоял сис5инит, теперь везде стоит системд, т.е. произошла массовая миграция с одного на другой. автор описывает этот процесс. с демонтулс на ранит никто не переходил и никакой трагедии не происходило, т.е. описывать нечего.
Поклонники systemd, однако, такие поклонники.автор слегка разработчик фрибсд. видимо, его купили
то, что systemd сложнее, чем init.d — это его недостаток, а не преимущество.
run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
Вопрос для личного образования, а не чтобы потроллить.
Нельзя. По фичам daemontools и runit сильно отстают от systemd, в s6 фич намного больше и он старается внедрить многое из systemd но с правильной архитектурой, но поддержки cgroups нет и в s6, насколько я помню. Зато мы получаем cgroups из коробки в docker, и, как по мне, этого более чем достаточно — никогда не понимал зачем нужны cgroups для традиционных системных сервисов (ну т.е. приятно, когда они есть из коробки, спору нет, но вот реальной пользы я от них для системных сервисов ни разу не видел и не слышал о таком).
ну т.е. приятно, когда они есть из коробки, спору нет, но вот реальной пользы я от них для системных сервисов ни разу не видел и не слышал о таком
я приводил кейс и могу повторить. Мы хотим распилить один большой мощный сервер на несколько задач, чтобы они не подрались за ОЗУ, за процессор, и при этом не хотим активировать своп (на сервере — mongodb, clickhouse, маленький postgres для метрик и куча http rest api).
Я говорил про пользу для системных сервисов (syslog, ssh, vpn, dhcp, cron, dns, smtp, etc.). Всё остальное, нужное именно нашему проекту, запускается в докере, и там cgroups и лимиты есть.
никогда не понимал зачем нужны cgroups для традиционных системных сервисовэто от нежелания ознакомиться с документацией по системд. они нужны например для того, чтобы можно было надежно остановить сервис, у которого форкаются процессы
Можно узнать, какие из стандартных системных сервисов ведут себя таким образом? Не форкают вспомогательные процессы — таких хватает, а оставляют их после себя получив SIGTERM?
Кстати говоря, cgroups для решения этой проблемы обычно не требуется, если сервис работает под выделенным системным аккаунтом то можно убить все процессы этого юзера через pkill -u USER, но обычно достаточно убить группу процессов (все нормальные сервисы обычно вызывают setsid(2)) через kill -PID. Если же сервис запускается под root, не сделал setsid сам, наплодил процессы которые сделали собственный setsid, да ещё и не реализовал подчистку запущенных процессов при получении SIGTERM — может не надо таким системным сервисом вообще пользоваться?
Всё это и есть типичнейший пример подхода systemd "do more" вместо "do less", при котором дополнительным усложнением героически решается теоретическая проблема, которая на практике вообще не существует.
можно убить все процессы этого юзера через pkill -u USERнельзя, если они могут форкаться в это время, pkill не atomic
может не надо таким системным сервисом вообще пользоваться?может не надо пользоваться супервизором процессов, который работает только если никто не делает резких движений?
может не надо таким системным сервисом вообще пользоваться?среди системных сервисов вы по собственной инициативе перечислили cron. а крон что делает? он форкает пользовательские задачи. любые. которые могут форкать все, что им взбредет в голову
[Unit]
Description=Test service
[Service]
Type=simple
ExecStart=/usr/bin/blalbla
ExecStop=/bin/kill -s SIGINT $MAINPID
[Install]
WantedBy=default.target
Это самый простой вариант.
А вот практически то же самое для daemontools/runit/s6, файл ./run в каталоге сервиса:
#!/bin/sh
exec /usr/bin/blalbla 2>&1Отличие в том, что при остановке сервиса убивать его будут через SIGTERM, а не SIGINT (вообще, SIGINT для сервисов, серьёзно???). В случае runit есть возможность изменить SIGTERM на SIGINT создав второй файл ./control/t:
#!/bin/sh
sv i .Выключать можно 100500 разными методами. Это пример из моего ближайшего шаблона, там надо такой посылать чтоб сервис убирал за собой сокет.
У меня скрипты эти написаны на 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Это всё абсолютно портабельно, повода для паники нет.
Ещё раз. Медленно. Есть стандарт. POSIX-совместимые sh. Все используемые варианты шелла, которые можно обнаружить в качестве /bin/sh в любых дистрибутивах *NIX — являются POSIX-совместимыми. И этот стандарт поддерживает довольно много всего, так что вполне можно писать достаточно сложные sh-скрипты, которые будут работать везде (разве что кроме винды, да и то, сейчас и это уже не так очевидно).
Кстати, есть вспомогательные утилиты вроде checkbashisms, которые могут подсказать если случайно в скрипте использовали фичу не входящую в POSIX sh.
csh к примеру не является совместимым.
Дополнительно могут различаться пути расположение самих пакетов и т.п. Как итог сделать универсальный запускатель во всех возможных дистрибутивах может быть затруднительно, даже с systemd. Дополнительно напомню все дружно кладут на использование только POSIX-совместимых инструкций shell. Кучу раз эти грабли собирал уже.
Так что с портабельностью ровно те же проблемы что и sysvinit и многих других.
Я в свое время смотрел кучу разных init систем. Из нормальных которые реально удобно пользоваться и дают все необходимое ровно две это openrc и systemd. И да у openrc при этом свой отдельный обработчик сценариев как и systemd. Это позволяет не зависеть от того какой там shell стоит в конкретной системе и дополнительно ограничивает художества которые делают некоторые люди.
Можете назвать хоть один дистрибутив, в котором csh/tcsh запускается как /bin/sh?
Пути расположения действительно отличаются (потому что предложенный DJB /package так и не стал популярным), но какое это имеет отношение к данной дискуссии? Разве в unit-файле ExecStart работает как-то иначе?
Админ может поменять. Внезапно ага.
Разве в unit-файле ExecStart работает как-то иначе?
В systemd можно прописать PATH и не указывать пути при запуске к примеру. Причем глобально это можно сделать.
Насчет же дискуссии могу сказать, что в большинстве случаев администраторы банально не обладают должной квалификацией. По этой причине unit в systemd позволяет не отстрелить ногу с ходу вполне приличная штука.
Админ может поменять. Внезапно ага.
Не может — у него пол системы ляжет. А вообще он может сделать rm -rf /bin — и что, надо быть к этому готовым и иметь запасной набор бинарников в /var/tmp/резервный-bin/?
В systemd можно прописать PATH и не указывать пути при запуске к примеру. Причем глобально это можно сделать.
Не может быть! В обычных sh-скриптах тоже так можно! Ну надо же, как здорово, что в POSIX sh додумались включить такую продвинутую и уникальную фичу systemd.
Вы издеваетесь? Всегда есть место, куда можно прописать глобальное значение 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 и никаких других переменных окружения по умолчанию у них не будет.
Разве в unit-файле ExecStart работает как-то иначе?если «иначе» это «не зависит от /bin/sh», то да. чтобы запустить шелл из юнитфайла, надо запускать =/bin/sh ...., ну или =/bin/script.sh…
я не думаю, что кто-то использует csh вместо шелла, но есть много других вариантов с разной степенью корявости. если вы протестировали свой скрипт в системе х, где /bin/sh это bash, он совсем необязательно будет работать в системе у, где это ash
"иначе" — это "не зависит от $PATH"
Скрипт будет работать везде, если писать его без башизмов и контролировать это тулзой вроде checkbashisms.
вы регулярно приводите примеры скриптов, которые не будут работать на моей системе (т.к. запускают бинари, которых у меня нет), несмотря на отсутствие башизмов.
Может это Вас шокирует, но Вы делаете ровно то же самое — приводите примеры unit-файлов, которые не будут работать на моей системе (т.к. для их выполнения нужен не установленный у меня systemd).
И если Вы нажмёте на кнопочку "Показать ветку комментариев", то убедитесь, что я привожу эти примеры не потому, что утверждаю что они запустятся на Вашей системе, а в подтверждение моего утверждения в начале ветки:
run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
И если Вы нажмёте на кнопочку «Показать ветку комментариев», то убедитесь, что я привожу эти примеры не потому, что утверждаю что они запустятся на Вашей системе, а в подтверждение моего утверждения в начале ветки:
run-скрипты daemontools/runit/s6 намного проще unit-файлов systemd.
у вас не выходит подтвердить это утверждение. получается только «нигде не работающие скрипты в простейшем случае ровно такой же сложности, как юнитфайл, но лишены всех его плюшек»
У меня Gentoo. Плюс из популярных без systemd есть ещё как минимум Devuan, Arch и Slackware. А вообще список достаточно большой: http://without-systemd.org/wiki/index.php/Linux_distributions_without_systemd
По-вашему, это благотворительность? Т.е. они пишут статьи для пользователей других дистрибутивов?
Давайте сойдемся на том, что есть дефолтная конфигурация дистрибутива и кастомная.
Насчет Slackware вообще не в курсе — его еще не похоронили?
Т.е. реально из Вашего списка только Devuan строго не systemd-дистриб.
Как предлагаете делать systemd-analyze critical-chain, например?
Если я, например в userspace что-то разрабатываю, как мне сделать такое? Startup finished in 1.297s (kernel) + 2.825s (initrd) + 8.695s (userspace) = 12.818s
Вы не поверите, но у меня за всю загрузку системы отвечает ровно один sh-скрипт размером 200-300 строк. Пример этого скрипта Вы можете найти в статье Как загружается Linux в разделе "Startup: /etc/runit/1".
Так что при желании измерить этот "userspace" можно тупо вписать несколько строк date между любыми этапами загрузки (они все в виде вызовов функций перечислены в конце скрипта). И, будем откровенны, насколько часто и насколько большому количеству разработчиков нужно замерять это время — и стоит ли их удобство в эти моменты установки systemd, со всеми его уязвимостями и "особенностями", большинству обычных юзеров?
Всё в одном файле — при обновлении приложений практически невозможно автоматически обновить код инициализации этого приложения. Например, когда обновляется ALSA, то пакет может просто заменить файлы /etc/init.d/alsasound, /etc/conf.d/alsasound, /etc/modules.d/alsa. А в моём случае админу нужно будет ручками править /etc/runit/1.
Нет поддержки всего на свете
Ну и сколько вы эти шашечки рисовали? А если надо будет поставить вдруг pulseaudio? Шашечки хорошо, но когда ехать-то?
Если я захочу заняться разработкой под андроид, например?
Что мне работодателю сказать, извини, дружок, через три месяца начнем, мне тут надо все запустить сначала?
Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают. Я правильно понял? Этим занимаются все нормальные разработчики и всегда. По полгода пилят софт, чтобы полсекунды выйграть.
Шашечки рисовал некоторое время. Это был интересный проект для саморазвития и изучения процессов, которые происходят при загрузке системы. Так что время не жалко.
Но любопытный факт в том, что на поддержку этого у меня за 15 лет ушло до смешного мало времени, хотя за это время много чего изменилось. При этом эти скрипты за 15 лет использовались на некотором количестве десктопов и серверов, причём не только мной. В общем, это только выглядит страшно, а на практике работает весьма неплохо.
При этом надо отметить, что в случае каких-то проблем при загрузке этот подход позволяет найти и исправить проблему практически моментально, потому что весь выполняющийся при загрузке код максимально краткий, простой и очевидный — при этом отладка аналогичных проблем в sysvinit, OpenRC и systemd требует намного больше времени и усилий, потому что там задействовано намного больше кода, файлов, конфигов, а в случае systemd ещё и сложных и местами глючных (или скажем политкоректнее "с не всегда очевидным поведением") инструментов.
Вы сейчас спрашиваете, какое количество разработчиков занимается профилированием и насколько часто они это делают.
Нет, я спрашивал о профилировании кода, выполняющегося при загрузке системы. Что касается профилирования обычных прикладных приложений/сервисов — я не понимаю, какое вообще отношение к их профилированию может иметь systemd, для этого существуют намного более практичные штатные инструменты.
300 строк — это максимально краткий, простой и очевидный код? А по пять строк юниты — это код сложный и запутанный, ну акей. Пока вы саморазвиваетесь в интересных проектах, люди деньги хотят зарабатывать. Если сравнить это с такси, никому ваше такси не будет интересно, если вы приедете через месяц после заказа, с криками, смотрите какие я тут шашечки нарисовал. Для себя ок, прикольно, не спорю, хотя есть и поприятнее занятия, как по мне. Но какой в этом business value?
Например, какие такие штатные инструменты позволяют оценить, сколько твоя программа отожрала при загрузке времени, в целом и в интеграции с другими сервисами?
Для анализа работы сервисов специально придумали логи и метрики — моя программа обычно выводит такую информацию в них.
Сколько времени мой сервис запускается в условиях когда одновременно запускаются вообще все сервисы — мне обычно не интересно, частично потому что такое случается только при редких перезагрузках серверов (а сервисы обычно обновляются/перезапускаются по одному), и частично потому что этой информацией сложно воспользоваться для чего-то полезного (она не покажет какой сервис нуждается в оптимизации). Но если вдруг мне это станет интересно — время затраченное на полную перезагрузку сервера и запуск всех сервисов легко увидеть на тех же метриках.
К слову говоря все данные systemd относятся к текущему серверу, а современные сервисы гораздо чаще всё-равно разворачиваются на кластерах, и статистику хочется смотреть по всему кластеру, а не по отдельному серверу — и для этого метрики намного удобнее systemd.
300 строк — это максимально краткий, простой и очевидный код? А по пять строк юниты — это код сложный и запутанный, ну акей.
300 строк на sh у меня делают то, что делает значительная часть кода самого systemd плюс значительная часть unit-файлов, которые systemd выполняет при загрузке системы (исключая те unit-файлы, которые запускают обычные сервисы вроде ssh/vpn/etc. — аналог этих unit-файлов у меня в ./run-файлах, тоже которые занимают меньше строк).
В общем, Ваша цитата это очередная попытка сравнивать тёплое с мягким, довольно типичная для любителей systemd — хотя никак не могу понять, почему это настолько распространённая проблема…
Но какой в этом business value?
Я получил простую и очень надёжно работающую систему, требующую минимум времени на поддержку. С успехом использую её 15 лет, на своём десктопе и десктопах нескольких друзей, плюс на серверах кучи проектов в которых я участвовал до появление докера (с докером что стоит на хосте стало намного менее принципиально), и пока что не вижу причин от неё отказываться — все известные мне альтернативы работают менее надёжно и/или требуют больше усилий на поддержку, а их основные достоинства в том, что они более популярны и/или поддерживают не нужные лично мне фичи. Так что business value в том, что я за 15 лет сэкономил кучу времени и нервов.
Я получил простую и очень надёжно работающую систему, требующую минимум времени на поддержку
Что может быть минимальнее, чем
dnf upgrade, например.
А вот тут вообще песня.
Да, в списке процессов болтаются всякие самозапустившиеся «сервисы» вроде /usr/libexec/gvfs-udisks2-volume-monitor, /usr/libexec/udisks2/udisksd, gpg-agent, /usr/libexec/dconf-service etc. без нормального runit-супервизора. Это немного раздражает, но без веских причин, скорее просто по принципу «потому что тишина должна быть в библиотеке!». По факту у них просто собственный жизненный цикл, кто-то их автоматом запустил когда они понадобились, и если они крешнутся, то этот кто-то их и перезапустит когда они снова понадобятся.
Ну да ладно. Вас уже не в ту степь понесло.
Какие-то метрики уже появились. Причем тут метрики и
процесс загрузки системы?
у меня за всю загрузку системы отвечает ровно один sh-скриптт.е. ваша система не живет в динамичном мире, в котором живут все остальные. в реальном мире набор запущенных сервисов не определяется жестко одним скриптом, а реагирует динамически на меняющиеся внешние условия
Этот скрипт не запускает никаких сервисов, он отвечает за необходимую инициализацию системы перед тем, как runit параллельно запустит все сервисы. Сами сервисы запускаются практически однострочными ./run-файлами, как Вы видели в примерах, и никакой проблемы в процессе работы запускать новые сервисы или останавливать/удалять/перезапускать/обновлять работающие нет.
Иногда цепочка вспомогательных утилит делающих exec друг в друга для задания ограничений сервису, напр.:
#!/bin/sh
exec 2>&1
exec envuidgid tinydns envdir ./env softlimit -d400000 /usr/bin/tinydns
а покажите цепочку, которая настраивает несколько приватных маунтов, мне такое часто надо
ну и кстати, /bin/sh не делает ваш скрипт посикс совместимым, в моей посикс совместимой системе нет ни envuidgid, ни envdir. в этом и польза стандартизации системд
Это всё абсолютно портабельносм выше. по сравнению с системд это все абсолютно непортабельно
У меня этот run-файл не менялся с начала 2000-х, когда я ещё использовал daemontools. Сейчас использую runit, а с ним в комплекте идёт утилита chpst, которая умеет делать всё то же самое, что и этот конвейер. Иными словами, если пишется ./run-файл для runit, то в нём гарантированно можно использовать chpst для этих целей, а если он пишется для daemontools — то можно использовать вышеупомянутые утилиты.
Что касается совместимости с POSIX sh, то она не требует ограничиваться в sh-скрипте исключительно командами включёнными в POSIX, иначе вообще практически ни один скрипт не может считаться совместимым.
Приватные маунты это прекрасно, но речь идёт о системных сервисах — кому из них нужны приватные маунты? А не системные сервисы запускаются в докере, где приватные маунты доступны.
Иными словами, если пишется ./run-файл для runit, то в нём гарантированно можно использовать chpst для этих целей, а если он пишется для daemontools — то можно использовать вышеупомянутые утилиты.а если пишется юнитфайл, то в нем гарантировано можно использовать синтаксис юнитфайлов. и это будет работать на любом мейнстрим дистре, в отличие от ранита и демонтулс
Что касается совместимости с POSIX sh, то она не требует ограничиваться в sh-скрипте исключительно командами включёнными в POSIX, иначе вообще практически ни один скрипт не может считаться совместимым.почему? посикс описывает набор утилит. все остальное — это зависимость не на посикс, а на что-то другое.
Приватные маунты это прекрасно, но речь идёт о системных сервисах — кому из них нужны приватные маунты?всем нужны, чтобы не видеть лишнего. но я строчку попросил не для системных сервисов(т.к. это умеет системд), мне и в простых скриптах надо
А вот практически то же самое для daemontools/runit/s6, файл ./run в каталоге сервиса:ну т.е. совсем не то же самое. чтобы убивать через сигтерм, в оригинальном примере достаточно удалить строку, он по дефолту так убьет. а не по дефолту (как в примере) делается одной простой строкой. но это не все отличия. в примере юнитфайла есть описание, в вашем примере никакого описания нет(нет, строка комментария не подойдет, описание из юнитфайла доступно программно для запущенных сервисов). в примере юнитфайла указано, куда этот сервис встраивается в дерево зависимостей, в вашем примере этого нет. и сделать это одной строкой нельзя. в примере юнитфайла автоматически работает огромное количество дефолтных плюшек, которых в вашем примере нет, потому что вы не слышали о пользе cgroups и т.д.
#!/bin/sh
exec /usr/bin/blalbla 2>&1
Отличие в том, что при остановке сервиса убивать его будут через SIGTERM, а не SIGINT
чтобы убивать через сигтерм, в оригинальном примере достаточно удалить строку, он по дефолту так убьет
В моём примере достаточно удалить файл ./control/t и он тоже по дефолту убьёт через SIGTERM — и, честно скажу, файл всегда удалить проще, чем строку.
а не по дефолту (как в примере) делается одной простой строкой.
А не по дефолту делается одним простым файлом из, по сути одной строки (если не считать #!/bin/sh).
в примере юнитфайла есть описание, в вашем примере никакого описания нет(нет, строка комментария не подойдет, описание из юнитфайла доступно програмно для запущенных сервисов)
Это правда, но лично мне всегда хватало имени сервиса чтобы с ним работать, можно узнать почему Вам его недостаточно и как в этой ситуации помогает длинное описание?
в примере юнитфайла указано, куда этот сервис встраивается в дерево зависимостей, в вашем примере этого нет
А это потому, что ни в daemontools ни в runit нет зависимостей. И, Вы не поверите, но они там нафиг не нужны — если какому-то сервису при старте не хватило какой-то зависимости (поскольку он случайно запустился раньше неё), то он тупо пишет в лог "ой", падает, и runit через секунду его перезапускает, что полностью решает проблему. В s6 зависимости есть, но на практике их отсутствие в runit никогда не создавало проблем, так что переходить ради зависимостей на s6 я пока не вижу смысла.
и сделать это одной строкой нельзя.
Вообще-то в s6 зависимость указывается именно одной строкой.
в примере юнитфайла автоматически работает огромное количество дефолтных плюшек, которых в вашем примере нет, потому что вы не слышали о пользе cgroups и т.д.
Я прекрасно знаю о пользе cgroups, просто я не вижу реальной пользы от cgroups на практике для системных сервисов — а все остальные, для которых польза безусловно есть, я запускаю в докере.
честно скажу, файл всегда удалить проще, чем строку.вы не с той стороны заходите. я имел в виду, что по дефолту этой строки нет, а если хочется, то можно добавить строку. что проще, чем добавить файл(нет, это делает не админ в командной строке, а разработчик сервиса в редакторе)
делается одним простым файлом из, по сути одной строки (если не считать #!/bin/sh).вам дали избыточный пример, который дает повод для критики непосвященным. в юнитфайле можно точно так же из одной строки(если не считать [Service]):
[Service]
ExecStart=/usr/bin/blalbla
я посчитал, это одинаковое количество символов с вашим скриптом. только тут на самом деле огромное количество фич включено по дефолту
как в этой ситуации помогает длинное описание?понятнее вывод systemctl list-units? но, как мы уже выяснили, если вам не надо описание, вы его можете не писать. а если надо, то вам поможет только юнитфайл
И, Вы не поверите, но они там нафиг не нужныне поверю, потому что я знаю, зачем они нужны. если, к примеру, у вас есть сервис, которому нужна база данных, то в системд он явно указывает зависимость. если вы не будете запускать сервис(а с сокет активейшн это превращается в «не будете пытаться коннектиться клиентом), то и базу данных никто запускать не будет(в отсутствие других клиентов базы данных). а как только понадобится запустить сервис, он стартанет и базу данных. все устаревшие альтернативы(включая апстарт с ивентами) вынуждены в такой ситуации просто сходу стартовать все, что в принципе установлено в систему, даже если оно может понадобиться только в следующее полнолуние, а может и не понадобиться вовсе
Вообще-то в s6 зависимость указывается именно одной строкой.как это помогает раниту и демонтулс?
я не вижу реальной пользы от cgroups на практике для системных сервисовхттпд — системный сервис? полезно ли на практике точно прибить его вместе со всеми форкающимися цги? „я не вижу пользы“ не всегда свидетельствует об отсутствии пользы, иногда это отсутствие знаний и вообще это странный аргумент против чего-то, в чем все остальные пользу видят
хттпд — системный сервис?
Нет. Системные — те, которые нужны для обслуживания системы, а не прикладных задач юзера вроде веб-сайта компании: acpid, agetty, atd, cups, cron, dhcpd, dns, syslog, mcelog, vpn, smtp, ssh, ну и docker.
в чем все остальные пользу видят
Ну так расскажите, какие конкретно реальные проблемы с любыми из вышеупомянутых сервисов помогут решить cgroups?
я уже несколько раз повторил: есть надежный способ убить все процесссы в сигруппе, нет надежного способа убить произвольное дерево процессов, которые в этот момент могут форкаться
Окей, повторю основную мысль ещё раз: systemd делает много ненужного, решает не существующие на практике проблемы, и за всё это приходится платить очень высокую цену (включая уязвимости в настолько критичной части системы).
Дальше идёт разбор конкретных фич, например cgroups, и мы пытаемся определить нужные они или нет. Вы утверждаете, что это крайне нужные и полезные фичи. Я утверждаю, что если использовать сервер определённым образом (запуская все наши прикладные сервисы вроде http и DB) в докере, то пользы от cgroups в systemd нет, поскольку под управлением systemd остаются только системные сервисы (вроде перечисленных мной выше), у которых тупо нет проблем, которые надо решать через cgroups. При этом я нисколько не спорю с полезностью cgroups, просто в моём случае я получаю управление cgroups через docker, а не systemd.
громкая критика системд слышна только от дилетантов, которые плохо разбираются и в сервисах в целом и в системд в частности.
кстати, раз уж он не в первый раз всплывает, рокет — сила, докер — могила.
и это, давно докер стал портабельным за пределы линуха(основной аргумент против сигрупп)?
и про уязвимости
Да, уязвимости докера меня лично сильно беспокоят. Но тут такое дело, по факту выбор ведь не между docker и systemd, а между systemd+docker или runit+docker — и второй вариант очевидно содержит намного меньше уязвимостей.
Что касается k8s и прочих альтернатив докеру — не имею ничего против, в контексте данной дискуссии абсолютно всё-равно какой инструмент используется для управления контейнерами и cgroups для контейнеров, вопрос в том есть ли какая-то реальная польза для cgroups для системных сервисов, или нет.
А как десктоп системы запускать в данной парадигме?
Писать простыни шелл скриптов — так уже проходили это, отказались. Эволюционировали дальше, опять отказались, родили системд.
Вы предлагаете вернуться к простыням обратно? А зачем? Чтобы безопаснее было?
Fedora, десктоп, 30% запущенных сервисов задетачены, мне для них что надо, баш скриптами врапперы писать? А зачем?
Не совсем понял, о каких таких специфичных для десктора простынях скриптов речь.
У меня 15 лет дома на десктопе runit. Да, в списке процессов болтаются всякие самозапустившиеся "сервисы" вроде /usr/libexec/gvfs-udisks2-volume-monitor, /usr/libexec/udisks2/udisksd, gpg-agent, /usr/libexec/dconf-service etc. без нормального runit-супервизора. Это немного раздражает, но без веских причин, скорее просто по принципу "потому что тишина должна быть в библиотеке!". По факту у них просто собственный жизненный цикл, кто-то их автоматом запустил когда они понадобились, и если они крешнутся, то этот кто-то их и перезапустит когда они снова понадобятся. А если выключить Xorg, то они все будут убиты автоматом. В отличие от системных сервисов, которыми я нередко управляю вручную через runit, нужды вручную управлять этими "сервисами" у меня пока не возникало.
Самозапустившиеся, кто-то их автоматом запустил, это как вообще?
Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.
В свое время только один инит скрипт, например для zookeeper, был строк под 200. Писало его человек 10 в общей сложности. Сколько времени убили, уйму просто. А могли бы зоокипер пилить вместо этого. Сейчас файл занимает пять строк и понятен любому человеку, а не только аутисту.
Сейчас чтобы запустить сервис типа zookeeper не нужен файл и на 5 строк, достаточно docker run --name some-zookeeper --restart always -d zookeeper.
А только потом запустить в докере zookeper, не забыв указать ему переменные окружения. А потом разработчик с соседнего отдела приходит и говорит, там это, баг у нас походу, давай попробуем сменить файлуху вот тут в сервисе на reiserfs, например. Только тут надо на 300 машинах, там половина центос 6,8, вот тут вообще опенвз стоит, тут вот центос обновили, но не до конца. А вот тут машина грузится долго, нам полсофта надо переписывать, че за хрень? А ты ему, щас погоди, чувак, давай через неделю другую приходи, следующие спринтов 10 твои, мне тут свой суперинит поправить надо.
Есть серверы, где докер, например, не заработает, тут как быть? Например, там убунта, в которой уже выпилили апстарт. И которую обновить нельзя, там кривой aufs с проблемами с dir permissions + отключен коннтрак.
Мир он такой, многогранный. Именно поэтому там существует и runit, и upstart, и по старинке, и systemd одновременно. Если вам чего-то тут не нравится или не надо, всегда найдется несколько сотен тысяч человек, которые думают по-другому.
Я еще хотел спросить, как реализовать планирование, например, сервис А запускается после сервиса B, до запуска сервиса C, но только если стартанул сервис Z, но пожалуй пусть это будет риторический вопрос.
пардон, докер это вообще не про это. Даже если вы упакуете все сервисы в докер, то такую цепочку в нем не реализовать. Только если не привлекать сторонние утилиты. docker-compose? Увольте, он ничего сложного не умеет. Получается опять возвращаемся ЛИБО к оркестрации (кубики+ансиблы и прочее), ЛИБО к systemd, но тезис коллеги выше в том, что если есть systemd, то докер уже не нужен, т.к. первый все уже умеет (изоляция, разделение ресурсов и much more). Паковать docker-контейнеры в systemd юниты можно, но при этом теряется часть прелестей самого systemd + много бойлерплейта.
что если есть systemd, то докер уже не нужен,
Это вы откуда такое утверждение взяли? Было утверждение, что systemd использует cgroups и этому есть свои причины, которые вам и привели неоднократно. Из-за этого, в том числе, использование докера необязательно, если вам нужны только cgroups.
Докер же — это не просто cgroups, это целый комбайн, там еще куча всего дополнительно намешано.
Было утверждение, что systemd использует cgroups и этому есть свои причины, которые вам и привели неоднократно
И что? Пускай использует. Я не против.
Из-за этого, в том числе, использование докера необязательно, если вам нужны только cgroups.
Эм. По факту из всего вышеперечисленного докер решает только две задачи:
1. пакетирование приложений и их доставка. systemd это не умеет. Но это умеют системы SCM + пакетные менеджеры (последние есть во всех современных дист-х)
Ну, и все равно настраивать среду под докер и как-то инициировать стягивание новых версий образов нужно (scm?)
2. изоляция окружений. Т.е. чтобы не было взаимовлияния. Потому что держать те же несколько версий php/python на одной машине — кошмар. И, да, докер с этим справляется хорошо. Другой вопрос — а нужно ли это всегда.
Все остальное — автоперезапуск сервиса, зависимости между сервисами, ограничение по процу/памяти и пр. — systemd прекрасно отрабатывает.
Лучше скажите — что Вы планируете делать для совмещения докера и systemd? Ну, предположим, что докер-контейнеру нужен маунт нфс, т.е. уже нужно зависимости между разными сущностями строить.
Утверждения были такие.
1. systemd умеет cgroups. Зачем это нужно, уже указали, не раз. В ответ на это наш коллега с «простой и понятной системой» с инит скриптом из 300 строк заявил, что ему это не надо, есть вот же докер, что еще надо.
На вопрос, что делать, когда докер по разным причинам запустить вдруг нельзя, наш коллега тактично отвечать не стал.
2. Докер не замена иниту и инит не замена докера.
Хотя наш коллега с «простой и понятной системой» и думает иначе.
Я знаю что такое докер, я ничего не планирую делать для совмещения systemd и докера. Зачем бы мне это надо было?
У меня 15 лет дома на десктопе runitу меня в течение бОльшего времени дома на десктопе то, что идет с дистрибутивом. процесс написания скриптов/юнитфайлов аутсортится разработчикам дистрибутива. никакого беспокойства по поводу «скриптов обижают» не испытываю
процесс написания скриптов/юнитфайлов аутсортится разработчикам дистрибутива
я честно скажу, что они это плохо делают, что для обычных инит-скриптов, что системд-юнитов. Возможно даже проблема не в разработчиках дистрибутивах как таковых (они попросту не могут знать специфику всего ПО), а в разработчиках конкретного приклада, который включается в дистрибутив. Но все равно от этого не легче.
Разумеется, все эти системы (daemontools/runit/s6) работают по одному принципу: сервис запускается в foreground (т.е. он при запуске не делает fork), т.о. процесс сервиса остаётся непосредственным child-ом утилиты-супервизора (supervise в случае daemontools, runsv в случае runit, etc.), и когда сервис крешится его супервизор моментально получает от ядра ОС SIGCHLD и перезапускает сервис. Никаких pid-файлов и уязвимости к race conditions (как в случае init.d-скриптов из sysvinit) здесь нет, всё работает 100% надёжно.
[Unit]
Description=Test service
[Service]
ExecStart=/usr/bin/blalbla
KillSignal=SIGINT
KillMode=process
[Install]
WantedBy=default.target
Но проще не заморачиваться и не указывать ни KillMode, ни KillSignal, тогда они будут control-group и SIGTERM соответственно. Дети почти гарантированно не выживут (только если они не ушли в сискол навсегда), поскольку через TimeoutStopSec прилетает SIGKILL.
> У нас нердов сложное отношение к изменениям
Ну конечно, всё сводится к психологической драме, а не к тому, что эти изменения создали проблемы там, где их раньше не было.
Да, systemd решает задачи, которые не мог решать старый init, и проходилось городить костыли. Ну и унификация между дистрибутивами конечно радует.
Но в то же время systemd привнёс дополнительную сложность и хрупкость туда, гдё её раньше не было. При этом он безальтернативен: на локалхосте можно использовать хоть arch + openrc хоть самосборный LFS + <любая дикая экзотика>, но на сервере будет какой-нибудь Debian- или RedHat-like LTS, и там systemd неизбежна. То есть с точки зрения «нерда» ситуация выглядит так: вот тут раньше был простой как топор кусок системы, о котором можно было даже не задумываться. Теперь тут будет сложная фиготень, которая много чего умеет, но иногда ведёт себя непредсказуемо.
Ещё раз: проблема не в том, чтобы что-то освоить. Не самый сложный в мире софт, в конце концов. Дело в том, что с init проблемы в духе «journald иногда начинает есть 100% проца» или «resolved странно себя ведёт» невозможны в принципе. А 95% новых крутых возможностей мне, например, не нужны. timesyncd всё равно хуже openntpd или chrony, journald по возможностям гораздо слабее rsyslog или syslog-ng.
Странности поведения это плохо, но вот проблемы с безопасностью в таком элементе системы это намного хуже. И количество проблем с годами только увеличивается, что является довольно естественным следствием увеличения сложности.
список не полный, т.к. не включает всего, что запускается из баша и вообще игнорирует 800-фунтовую гориллу «написанный кривыми руками скрипт»
Смешно. Попробуйте, ради спортивного интереса, сравнивать продукты из одной категории с systemd: daemontools, runit или s6 — на всех троих вы найдёте ровно одну смешную CVE 2006-го года для runit. При использовании daemontools, runit или s6 для запуска системных сервисов в памяти не находится ни одного процесса bash или sh (имеется в виду когда они уже запустились, т.е. 99.999% времени работы системы).
Что касается проблем с bash — даже не подумаю их оспаривать. Кстати говоря, автор s6 создал язык execline, который как раз позволяет решить проблему портабельности sh-скриптов (а заодно и уязвимостей bash), и даёт возможность писать ./run-файлы сервисов без использования sh.
daemontools, runit или s6 — на всех троих вы найдёте ровно одну смешную CVE 2006-го года для runit
Отлично! Значит, тот http-сервер на bash+netcat, что я написал пять лет назад, самый безопасный в мире! Постойте, или это потому, что он мало где используется и к нему не приковано внимание специалистов по безопасности?
init запускал стартовые сценарии, а те запускали демонов.а когда надо было запустить/рестартануть демона на работающей системе, то стартовые сценарии запускалиь рутом из его рабочего шелла. и наследовали все окружение(не только переменные, все параметры процесса вроде лимитов и т.д) и при определенном выстраивании звезд все взрывалось. но не всегда, часто все работало и поэтому до сих пор есть люди, думающие, что это может работать в принципе.
вместо этого ветвистая клюква из 600 файловесли у вас 600 юнитфайлов, у вас было бы 600 глючных стартовых сценариев с простынями копипасты
еще и на своей шине виситэто не его шина. шина появилась гораздо раньше. не для того, чтобы насолить тем, кто привык запускать скрипты руками, а для того, чтобы избежать 600 криворуких реализаций ipc. конкретная реализация шины не лишена недостатков(повторюсь, они были и до системд), ведется работа над более лучшим вариантом
там, где хватает простых скриптов и утилиты daemonэти скрипты сложные (*), правильно работают только если повезет и хватает их только если игнорировать все ситуации, в которых их не хватает
*) сравнение сложности первого попавшегося скрипта с юнитфайлом:
простой скрипт
сложный юнитфайл
и не забываем, что простой скрипт включает
. /etc/rc.d/init.d/functions
и
. /etc/sysconfig/network
Сколько сейчас доля FreeBSD/NetBSD/OpenBSD в интернете?
Как скоро я смогу там запустить Clickhouse, например, добавить еще 20 фронтендов, пяток базенок mysql в HA, добавить немного мониторинга и автоматическое скалирование в случае изменения метрики, которая состоит из нескольких параметров, вычисляемых lua скриптом, который встроен в балансировщик? Часть системы надо еще разбалансировать по географически регионам, потому как клиенту важно получить ответ по наиболее коротким проводам. Часть системы в облаках надо разместить разного рода, потому как по стоимости это будет подешевле, чем свою SDN строить.
понимаете про что я?
Сколько сейчас доля FreeBSD/NetBSD/OpenBSD в интернете?
Как скоро я смогу там запустить...
Вы постеснялись почему-то ответить. Вместо этого занимаетесь демагогией про генный код. Зачем?
init здесь при том, что все вышеописанное предполагает одновременное использование минимум пяти десятков разных сервисов на каждом сервере, общим количеством более сотни, часть из которых вам вообще не принадлежит.
Мы до бекендов еще даже не дошли, давайте с фронтендами хотя бы закончим.
Как вы будете решать эту проблему с помощью FreeBSD/NetBSD/OpenBSD, где у вас c 1994 года ничего не взрывается?
Вопросы о моей компетенции я оставлю своим работодателям и партнерам все же. Вы бы лучше о своей позаботились.
это дурацкий вопрос? Как запустить на этом всем что-то сложнее мейлрелея и фтп — дурацкий вопрос?
Хехе. Что же в них дурацкого?
Я троллей не кормлю, кстати, так что предлагаю на этом и завершить. Идите погружайтесь в свое чувство собственного величия где-нибудь в другом месте.
Это из реального проекта-продукта.это поделие не будет работать нигде, т.к. не найдет /etc/rc.subr, дальше можно не ходить
# cat dbmaster.in
#!/bin/sh
# PROVIDE: dbmaster
# REQUIRE: LOGIN
. /etc/rc.subr
код как код. читается легко, отлаживается тоже.у меня претензия была не к читаемости, а к нерабочести
. читать как include, далее указание модуля с функциямия знаю, как его читать ( вы ведь отвечали на habr.com/ru/post/438698/#comment_19709004, быстро теряете нить разговора), я ж русским по белому написал, что этого модуля оно не найдет и работать не будет. потому что вы смогли отладить его в своей системе, но не смогли отладить его во всех остальных, в которых никакого /etc/rc.subr нет
я бы поостерегся делать столь поспешные выводы,попробуйте без «бы», а то у вас плохо получается
дабы не выглядеть пафосно глупым =)
этот код работает сейчас в каждой freebsd/netbsd копиикому это интересно в топике про системд? тут у всех линух и ваше поделие ни у кого не работает. просто потому, что использование посикс шелла не в состоянии обеспечить портабельность, у вас даже *бсд поддерживается только пара из всего зоопарка
Добавляем условия, которые в 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?
Вот и все у вас так, через назад.
С таймауатми понятно, они тут по количеству лампочек в потолке, акей.
Остальную часть сообщения вы опять тактично проигнорировали.
rctl -a jail:httpd:memoryuse:deny=2G/jail
или как? Потому как иных лимитов я не нашел для процессов.
А как это добавить вот к вашему коду из 30 строк? Там релоад можно будет сделать? Или только рестарт?
А если процесс запущен из-под юзера с одними лимитами, а rctl задаст другие, что будет? Как вообще проверить это при старте системы? У меня что-то в телефон не влазит вся инфа эта, можете вкратце описать? Или опять сольетесь? Да вы не переживайте, у меня много еще вопросов.
даже не знаю что сказать…хочется сказать, что юнитфайл сложнее, но не выходит?
Я из практики.некоторые на практике в русскую рулетку выигрывали. это как-то свидетельствует о безопасности упражнения?
бред какой-то.у вас во фразе «я не понял» несколько ошибок
программы-демоны в unix стартуют, работают, останавливаются.но не всегда
Нет.так проще юнитфайл или сложнее? я запутался
systemd нерационален и монструозен как старт-топ подсистема.системд это далеко не только старт-стоп подсистема. ну и о рациональности лучше судить тем, кто может отличить простой файл от сложного
freebsd:т.е. в 2019 году вы все еще не знаете, что в репе системд лежит системд-проект, а не системд-пид1? когда на входе мусор, на выходе будет то же самое, и так у вас со всеми постами
$ cat /etc/rc.subr /etc/rc /usr/src/sbin/init/init.c /usr/src/sbin/rcorder/rcorder.c
вообще полезно заглядывать в исходный кодчто же вам помешало заглянуть?
например, github.com/systemd/systemd/blob/master/src/core/main.c в два раза меньше строк, чем у ваших файлов. или наоборот, попробуйте find /usr/src -name '*.c' | xargs cat | wc -l
кстати, скилл шеллскриптов вам надо подтянуть, xargs тут лишняя сущность, find сам умеет запускать программы
расскажи мне про сложность еще.
рассказываю:
$ git clone github.com/freebsd/freebsd --depth 1
$ find freebsd/ -name '*.c' -exec cat {} + | wc -l
13330548
про что еще рассказать?
эти скрипты сложные
даже не знаю что сказать…
Я бы сказал, что не освоившим элементарный синтаксис POSIX shell не место в профессии. А если добавлю, что init / rc куда как гибче и понятнее systemd меня ластоногие вообще втопчут в лёд… :)
Скажите, а приколы вроде вот такого из комментария выше — это точно элементарный синтаксис POSIX shell? А то в учебнике почему-то написано, что со знака # начинаются комментарии...
# REQUIRE: redisdbИнтересно, какой сценарий "узнавания" этой информации? Вот, допустим, "продвинутому" разработчику после колледжа старшие коллеги сказали написать комментарии для кода на C++. После этого он что, идёт читать маны по rcorder? Где в вашем комментарии логика?
Но это никак не сделает rcorder обязательным для изучения после колледжа всеми разработчиками, а REQUIRE — частью синтаксиса POSIX shell.
Если вы считаете как-то по-другому — возвращаю вам ваш RTFM.
Попробуйте начать с RTFM, сэр.как далеко вы продвинулись в чтении мануалов по системд?
Это относится к фреймворку rc.d во FreeBSD, кстати весьма простому, но это POSIX shell позволяющий реализовать любую логику, которая вам только может быть необходима, а не ту, которую решили использовать за вас хотите вы этого или нет.
Учитывая, что в каждой дистрибутиве *nix что-то своё да выдумали — да, скрипты инициализации становятся сложными.
Вы так пишете, как будто нет этого безумного зоопарка из всевозможных клонов Linux, тонкости которых, внезапно, тоже надо изучать.
Вообще, я думаю что systemd уже начал геноцид расово-неправильных обитателей этого отмороженного GPL континентa, адептом чего и является автор статьи, и это ни к чему хорошему, в итоге, не приведёт.
это POSIX shell позволяющий реализовать любую логику, которая вам только может быть необходимасистемд позволяет запускать все, что угодно, включая посикс шелл, реализовывающий любую логику
безумного зоопарка из всевозможных клонов Linux, тонкости которых, внезапно, тоже надо изучатьсистемд как раз приносит порядок, изучать надо только системд
Вообще, я думаю что systemd уже начал геноцид расово-неправильных обитателейсистемд это просто программа, она ничего начать не может. я вижу, вы недовольны тем, что есть такая программа, которая приносит другим людям много пользы, но почему это вас так злит? вы не хотите, чтобы другие люди извлекали пользу?
отмороженного GPLвас гпл в детстве покусал?
адептом чего и является автор статьиавтор статьи является разработчиком фрибсд, как вам такой нож в спину?
это ни к чему хорошему, в итоге, не приведётчто вас сильнее огорчает — отмороженность контента или его геноцид?
системд как раз приносит порядок, изучать надо только системд
Да-да, именно об этом я и писал. Деградация профессии.
вы недовольны тем, что есть такая программа,
Вообще, меня вся эта возня больше интересует ну примерно как естествоиспытателя, который наблюдает за жизнью колонии каких-нибудь бактерий. То есть любопытно, можно выявлять зависимости и делать прогнозы.
Меня беспокоит лишь только чтобы эта бактерия не распространилась слишком широко уничтожив большую часть остальной жизни. Потому что разнообразие это необходимое условие для развития и эволюции.
вас гпл в детстве покусал?
Как атеиста меня в некотором роде, да, огорчает любое проявление религиозной веры, а GPL теперь для некоторых это стало чем-то вроде секты. На Habr это выражено не так ярко, что не отменяет самого факта.
Деградация профессии.как называется профессия, изучающая различия в деталях загрузки скриптов между дистрами и сколько тысяч дистров вы уже изучили?
Вообще, меня вся эта возня больше интересует ну примерно как естествоиспытателя, которыйпишет книгу «как управлять вселенной, не привлекая внимание санитаров»?
Как атеиста меня в некотором роде, да, огорчает любое проявление религиозной веры, а GPL теперь для некоторых это стало чем-то вроде секты.зачем вы заглядываете в линуховые топики, вас никто не предупредил, что там ядрго гпл? или иначе придется сидеть в одиночестве и могут возникнуть мысли, с той ли стороны секта?
Я бы сказал, что не освоившим элементарный синтаксис POSIX shell не место в профессииа неосвоившим элементарный синтаксис юнитфайлов?
А если добавлю, что init / rc куда как гибчето я отвечу, что шелл скрипты отлично запускаются из системд, он вообще изначально автоматически умел работать в системе, где еще скрипты из init.d не переделали в юнитфайлы, переделывание в юнитфайл это просто способ получить еще больше плюшек.
и понятнее systemdместо ли в профессии тем, кто не осилил элементарный системд?
Во-вторых, автор столкнулся с вполне конкретным кейсом, который уже упоминался. К тому же, я допускаю, что журналд не так часто ломается. А если ломается, ну, уже есть опыт — куда копать (но это не имеет отношения к сложности самой технологии, а к степени ее внедрения и распространенности)
В третьих, автор — нытик. Рассказывает какой плохой системд и как хорошо жилось с инит-скриптами.
В четвертых, инит скрипты хоть и проще (проще начать их писать абы как по примерам), но что-то сложное на них сделать… и к тому же они рождают весьма странных кадавров.
Короче — мимо. Но спасибо за попытку.
Во-первых, статья 2016-го года.
Простите, а что это меняет?
Во-вторых, автор столкнулся с вполне конкретным кейсом, который уже упоминался. К тому же, я допускаю, что журналд не так часто ломается. А если ломается, ну, уже есть опыт — куда копать (но это не имеет отношения к сложности самой технологии, а к степени ее внедрения и распространенности)
Автор столкнулся с невозможностью восстановить систему.
В третьих, автор — нытик. Рассказывает какой плохой системд и как хорошо жилось с инит-скриптами.
Зачем же вы сразу ярлыки лепите? Автор в недоумении, почему внедрение новой технологии усложняет его жизнь. Думаю если бы systemd работал как часы то и подобной статьи не было бы.
В четвертых, инит скрипты хоть и проще (проще начать их писать абы как по примерам), но что-то сложное на них сделать… и к тому же они рождают весьма странных кадавров.
Плохо можно писать на любом языке, шелл тут не исключение.
Короче — мимо. Но спасибо за попытку.
Да пожалуйста, я не собираюсь вас переубеждать.
Плохо можно писать на любом языке, шелл тут не исключение.
Это точно — не исключение. Плохо писать можно на любом языке, но на шелле… ух как на шелле можно плохо писать… Не, хорошо тоже можно, но плохо — намного проще, и вот в этом шелл — исключение.
P.S. Ненавижу systemd. И pulseaudio.
Автор столкнулся с невозможностью восстановить систему.интернет большой и в нем встречается множество людей, не стесняющихся поделиться своей некомпетентностью.
Автор в недоумении, почему внедрение новой технологии усложняет его жизньавтора никто не заставлял пересаживаться за компьютер, мог бы и дальше сидеть со счетами
Думаю если бы systemd работал как часы то и подобной статьи не было бы.из приведенной статьи никак не следует, что системд не работал как часы. загрузка сломалась, но ничего не указывает на вину системд. может у него лвм умер или еще что
My name is Igor Ljubuncic. I am currently working in a software company as a Developer Advocate. I have had a prolific career in the hi-tech industry, spanning medical, high-performance computing, data center, cloud, and hosting domains, with emphasis on complex problem solving and the scientific method. My public porfolio covers 15 patents, 15 books, several open-source projects, numerous articles published in leading journals and magazines, presentations at prestigious international conferences like LinuxCon, CloudOpen, OpenStack days, IEEE events, and more.
Автора сложно заподозрить в некомпетентности и неумении пользоваться компьютеромлегко, я дал развернутый ответ парой комментариев ниже
Книги — ну, тоже не показатель.
Аппелировать к масштабу личности не стоит. Как говорится, и на солнце есть пятна, а когда давят авторитетом, то все становится только еще запущенней.
ntpd_intres[1884]: ntp_intres.request: permission denied
systemd там нет. А это обычный race condition, когда ntp запускается пораньше dns, оно это не осилило.
Есть баг, его вроде даже починили. Починят и это, дело-то житейское.
Комментатор там последний не доверяет systemd, но доверяет старому доброму ntpd, что его от проблем не спасает, очевидно, из-за багов в самом ntpd. Таки кому верить-то?
Чем это отличается вдруг от ситуации с timesyncd?
Проблемы в ntpd несомненно исправляют, уже который год, но зачем-то люди переходят на cronyd, например. Тоже велосипед.
Ну и вас никто не заставляет же использовать timesyncd, если вы не хотите, также как никто не заставляет использовать ntpd. Выбирайте любой софт, там везде баги есть, у каждого свои. Баги есть даже в софте, который придумали еще в 80-х годах.
Нормальный процесс, ничего экстраординарного. Если всякий разный софт, предоставляющий один и тот же сервис, соответствует одному стандарту, как вы определяете, какой из них «велосипед», а какой нет, в каком стоит править баги, а какой этого недостоин?
С тем же успехом можно рассуждать на тему того, что в линукса нельзя поменять ядро. И я имею в виду — не версию ( скажем, с 4.4.* на 4.20.*), а именно на замену на что-то принципиально другое. Ну, не нравится мне линукс-ядро. Какой выход?
P.s. понятно, что можно перекатиться на другую ос, но это другая история
Для тех, кто по каким-то причинам не хочет использовать systemd отсутствие альтернативы это проблема.религиозные убеждения антипрививочников никого не волнуют. либс тоже нигде поменять нельзя и мир еще не рухнул
религиозные убеждения антипрививочников никого не волнуют
А это здесь при чем?
либс тоже нигде поменять нельзя и мир еще не рухнул
Альтернативы libc существуют: https://www.etalabs.net/compare_libcs.html
Для тех, кто по каким-то причинам не хочет использовать systemd отсутствие альтернативы это проблема.
Если вы смените libc, то сменить systemd будет вообще не проблема.
А это здесь при чем?при том, что если вам что-то показалось, то никто не метнется для вас делать отдельный дистрибутив
Альтернативы libc существуюткак и альтернативы системд. но только что вам было мало существования альтернатив
Вообще-то в Debian ещё не так давно можно было использовать фряшное, хурдовое и всякие другие ядра. Какой практический смысл ХЗ. С системД видимо эта фича отломалась (гуглить лень).
systemV, systemd, Upstart, runit, OpenRC, epoch, finit
кастомные на основе любых вышеперечисленных в любых позах.
То, что вы не можете поставить любую из коробки, не означает, что нет свободы выбора. Это лишь означает, что разработчики просто забили на унылый и устаревший софт и вы теперь с ним остаетесь один на один, без ансамбля, свободно выбирать и использовать.
CentOS 6.x еще использует sysvinit, а его еще дофига. Как-то они там живут, софт еще обновляют. Вам кто мешает делать тоже самое?
Очередной пруф, что смузихлёбы докерные ничего дальше доцкера не видят. upstart там.
На сервере CentOS6 не катит в первую очередь из-за скорого EOL. На старых, немощных серверах как пускалку жабоприложений можно было бы ещё лет 5-7 использовать.
На десктопе каждый пляшет как он хочет, но десктоп бывает не только дома, а в том же ынтырпрайзе, где за «весь день ковырять сломанный линукс» не поймут-с. Поэтому проще плыть по течению, хороших дистрибов без systemD уже НЕТ! :(
Ну, простите, вы сильно в меньшинстве, по сравнению с комьюнити.
Убедить народ перестать быстро ездить и начать снова месяцами рисовать шашечки будет действительно сложно. Платят, логично, за поездки. Шашечки еще практикуются пыльными админами, которые бесконечно отстали от жизни в своих пикейных жилетах, но это в пределах статистической погрешности. Все остальные зарабатывают. Плыть против течения весьма неконструктивно, дорого и весьма недальновидно. Вы быстро устанете и можете утонуть. А течению вообще на это глубоко все равно.
Я думаю дискуссию можно завершать. Переубедить друг друга у нас не получится. Наше мнение ни на что не влияет.
Все зависит от количества ресурсов и времени в вашем распоряжении. Можно попробовать изучить технологию, можно использовать другую, можно сменить профессию.
Код открыт, документация тем более. Есть гитхаб, где можно открыть issue, есть каналы в IRC и слаке. Есть курсы, опять же. Ничего невозможного.
Не хотите учиться, в репозиториях много софта, берите любой.
Но стоять на месте, когда все уже улетели, получится недолго.
Переубеждать вас у меня желания никакого нет.
Есть желание поделиться информацией, как ее использовать — исключительно ваш выбор.
Я хочу понимать систему, которую я поддерживаю, так как это критично в ситуациях, когда ее надо чинить.
нет, вы хотите, чтобы вам кто-то сделал новую систему, а вы ее автоматически продолжали понимать, т.е. чтобы в ней не было изменений. старую понятную систему у вас никто не забирал, а новую на свой лад вам придется делать самостоятельно
Нет. Проблема не в нежелании учить новое — любой успешный ITшник постоянно учит кучу нового — а в нежелании иметь дело со сложными, хрупкими (вследствие сложности) и дырявыми (ещё одно следствие сложности) инструментами — тем более, что доступны намного более простые и надёжные альтернативы.
И когда нужно сделать выбор, на изучение чего потратить своё время — предпочтение отдаётся более простым и надёжным инструментам, а не сложным. Не потому, что последние "сложнее учить", а потому, что КПД со сложными инструментами ниже — с ними больше проблем в эксплуатации, приходится учить больше и дольше накапливать личный опыт для того, чтобы обрести достаточный контроль над сложным инструментом и добиться от него нужного результата.
Да, в длительной перспективе, если нужно решать сложные и не типичные задачи, со временем КПД использования сложного инструмента может сильно обогнать простой инструмент, и, таким образом, окупить затраченные на него усилия. Именно по этой причине в некоторых случаях я предпочитаю использовать более сложные инструменты — например vim и mutt. Но запуск сервисов это на много порядков более простая задача, чем то, что требуется от редактора и почтового клиента, поэтому в этой области сложный systemd — это однозначный overkill и нужный мне результат абсолютно точно можно получить от runit, причём с намного меньшими усилиями.
Мне нравятся инструменты, которые позволяют реализовать именно нужный мне результат, и содержат при этом как можно меньше не нужного мне функционала — это обычно делает такие инструменты проще, надёжнее и безопаснее. А вот универсальные инструменты, которые подойдут каждому — нередко сложные, не эффективные, глючные и дырявые. Поэтому я выбираю универсальный инструмент только если у меня большая и сложная задача, для которой сложно выбрать простой/специализированный инструмент так, чтобы была гарантия, что его не придётся в срочном порядке через пару месяцев менять на универсальный, потому что функционала простого тупо не хватило.
Для запуска сервисов никаких "простыней на баше" не требуется — ./run-файлы Вы видели выше. А свой скрипт для загрузки системы я на продакшн сервера и не тяну — я уже писал выше, что на этих серверах я тупо ставлю докер и настраиваю регулярное обновление ОС, после чего всё остальное делается в контейнерах, так что мне пофигу, какой там дистрибутив и что используется для запуска сервисов включая докер — в настолько базовой конфигурации они все работают достаточно стабильно, чтобы это не имело значения.
И я полностью согласен, что в большинстве случаев даже сложное и немного глючное апстрим-решение лучше нетривиального самописного. И согласен, что деньги платят за фичи, а не такие служебные обвязки. (Но если возможно обойтись тривиальным самописным — нередко это получается быстрее, надёжнее и дешевле.)
А вот с тем, что runit/s6 это устаревшие и/или выпиленные отовсюду технологии — не соглашусь, равно как и с тем, что systemd это прекрасная технология. Если вспомнить историю как проходило голосование за systemd в Debian, как распределились голоса, как в итоге его пропихнули, как появился Devuan, и факт срача в каждой статье про systemd — станет очевидно, что очень многие не считают его прекрасной технологией.
В современном продакшне никто не будет в здравом уме разрабатывать и поддерживать самописные простыни на баше, да еще взамен технологий, используемых в апстриме. Их просто невозможно придумать, написать и отладить за вменяемое время
Я бы обратил внимание на то, что эти велосипеды придется еще поддерживать. Завтра придет заказчик и скажет, что ему нужна версия операционной системы +1 к текущей, т.к. требования безопасности и т.д. И человек, который закостылил эти скрипты — попадет впросак, т.к. ему их придется переписывать, отлаживать по второму кругу. Стоимость поддержки будет большая. Лучше идти синхронно со всем остальным миром )
В большинстве случаев это так, но не в 100%.
Стороннее решение тоже нужно поддерживать. Наличие апстрима — это только надежда на то, что поддержкой будет заниматься кто-то другой, но на практике апстрим может быть не заинтересован в решении нашей проблемы (в принципе, или в критичные для нас сроки). И в этом случае мы приходим к выбору что поддерживать — форк апстрима или свой велосипед, и первое не всегда проще и дешевле в длительной перспективе.
Поддержка велосипеда становится проблемой если велосипед стал достаточно сложным — поэтому я выше специально уточнил, что тривиальное самописное решение может оказаться дешевле, и я имел в виду как раз поддержку.
Ну и последнее — если все будут только идти "синхронно со всем миром" и пользоваться готовыми инструментами — откуда эти готовые инструменты будут вообще браться? Большинство из них начинались как велосипеды.
[ asilenkov@dev01 ~]$ sudo stat /proc/1/exe
File: `/proc/1/exe' -> `/sbin/init'
А нет, показалось.
На сервере CentOS6 не катит в первую очередь из-за скорого EOL.
Вот эта к чему информация? Как она связана с утверждением, что центоса6 еще дофига? Да никак не связана. Центоса 6 еще дофига, до EOL есть еще время обновиться. В здравом уме с нуля никто его сейчас ставить не будет, даже как пускалку жабоприложений. Есть для этого более подходящие средства. Но обновляться он таки будет, еще до 2020 года.
Последнее предложение я вообще не понял, ну да ладно.
А докер-то поизучайте, пригодится, ничего в нем сложного нет.
upstart тамтам в качестве бинаря апстарт, а в качестве скриптов — теплый ламповый init.d, скрипты под апстарт они не переделали
в том же ынтырпрайзе, где за «весь день ковырять сломанный линукс» не поймут-са дома, значит, весь день убить на какую-то бесполезную глупость — нормально?
один амбициозный разработчик привлек себе фонд, сделал проект, договорился об интеграции.это проекция? не получилось привлечь фонд и договориться об интеграции? у системд нет никакого фонда и договора об интеграции тоже нет. а проект сделали, да. потому что работали, а не постили глупости.
написать старт-стоп-управление систему, 2 месяца-1человек и навскидку 40-60 страниц С кода, startd + startctl с общением через сокет, но таки никто толком и не способился довести нечто подобное до конца за 15 лет.и это свидетельствуют о глобальном заговоре рептилоидов, а не ошибке в оценке сложности?
все зарабатывали для себя.опять проекция. особенно, с учетом отсутствия результата в виде 40-60 страниц.
www.ocsmag.com/2016/10/19/systemd-progress-through-complexity
трудно ожидать много, когда статья в первом же предложении сообщает, что системд — event-based, хотя он на самом деле наоборот, это ж главная техническая причина, почему его начали делать вместо ивент-бейзд апстарта(еще была лицензионная).
потом он приводит эволюционную аналогию, упорно не замечая, что системд уже занял доминирующее положение, задвинув конкурирующие виды в узкие ниши.
дальше демонстрирует, что с гномом тоже не разобрался.
первая проблема, с которой он столкнулся: нет консолей. это не особенность системд, если сломать иниттаб, но в сис5ините консолей тоже не будет. и я прекрасно помню загрузки с init=/bin/bash в качестве лекарства для «простого и надежного» сис5инита.
зачем-то решил, что гугл находит множество советов по починке сис5инит не потому что с ним часто возникают проблемы.
запутался в четырех компонентах, забыв включить в список компонентов сис5инит все утилиты, к которым обращаются скрипты.
не понял, почему базы данных хранят не в текстовых файлах, не осилил journalctl -D… (и интуиция не подсказала, что программе, работающей с файлами, должно быть можно указать их расположение), выдал сумасшедшую идею, что базы данных пишут для облегчения жизни разработчиков баз данных, а не их пользователей.
(кстати, journald запускается раньше, чем запускался сислог, т.е. в сис5инит ошибка на таком раннем этапе вообще в лог не попадет).
не знаком с fhs(явно потому, что как позже заявляет, использует интуицию вместо информации) и не знает, чем отличается /etc/ от /usr/lib/, не понял, что юнитфайлы, которые должны быть в /etc/ (написанные руками, а не идущие в комплекте с пакетом), будут в /etc/. назвал свое заблуждение «well known convention».
описал, каким молодцом он видит себя(подразумевая, что это системд во всем виноват, ведь не мог же такой молодец не справиться, если бы системд не держал его за руки).
показал, что не любит объектно-ориентированный подход, но не показал, в каком месте юнитфайла он его заметил
ну и проблему так и не решил. что характерно, у федоры есть багтрекер и есть разработчики системд, т.е. менее интуитивная личность могла бы как минимум зарепортить проблему. не проблему «я не прочел ман», а проблему сломанной загрузки. это ведь федора отвечает за то, чтобы федора грузилась. вдруг эта проблема может всплыть еще у кого-то. из предоствленного описания видно, что не смог успешно отработать systemd-journal-flush.service, я бы его отключил и посмотрел, куда загрузится дальше
можно начать с раздела The systemd for Administrators Blog Series
Апологеты: systemd модульный. Вот по бинарю на каждый модуль: systemd, udev, journald…
Противники: systemd монолитный. Я не могу взять систему с systemd и заменить отдельно init и rc на, например, SysVInit и OpenRC соответственно, оставив при этом остальные модули, такие как udev и journald.
И хоть формально оба правы, практический смысл утверждения апологетов systemd от меня ускользает.
И насчет криков — это не разработчики journald тут кричат, а скорее противники systemd. Как и всяческие меньшинства. Им же нужно заявить о себе.
И, да, кстати, я не против OpenRC и прочего — решения неплохие, но, к сожалению, не мейнстримовые.
А то я видел и много заявлений о необходимости реестрв в Линуксе.
Касательно реестра — он уже здесь. Где по-Вашему хранятся настройки кедов и гномов, если не в подобии реестра ????
Вы чего? Systemd состоит из целой плеяды программ.
Возможно, суть моих опасений от этого не меняется
Касательно реестра — он уже здесь. Где по-Вашему хранятся настройки кедов и гномов, если не в подобии реестра ????
Ну, слава богу, пока есть возможность сидеть не под кедами или гномом. Хотя вроде как в гноме настройки храняться в XML файлах. Или я опять ошибаюсь?
Возможно, суть моих опасений от этого не меняетсяесли опасения это «тащить всю функциональность в один гит репо», то вам надо посмотреть на модель разработки фрибсд(той самой, которая юникс, о потором забыл системд) и ужаснуться. это про системд-проект.
а основным мотиватором системд-пид1 был лончд из макоси(тоже юникс, кстати) — на макось равняться православнее, чем на винды?
С точки же зрения обслуживания… Ну, такое себе. Система сложная, но я выше писал, что сложная система может быть простой в эксплуатации, скрывая все эти ужасы от юзера. Вопрос в том, что будет когда она сломается )
тащить всю функциональность в один гит репо
можно пояснить? Я против монореп ничего не имею. Это вообще больше религиозный вопрос, т.к. и монорепы, и куча маленьких микрорепозиториев имеют свои проблемы. И опять же повторюсь, что и для тех, и для тех нужен свой собственный тулинг, чтобы с ними эффективно работать.
evgenyk
Ну, слава богу, пока есть возможность сидеть не под кедами или гномом. Хотя вроде как в гноме настройки храняться в XML файлах. Или я опять ошибаюсь?
а какая разница КАК они хранятся, извините? Они могут быть в виде единой БД, могут быть россыпью относительно стандартных xml в единой структуре каталогов. Вот посмотрите — dconf
Есть еще такая история, но что она редактирует — я вообще не в курсе.
В этом главный недостаток systemd в сравнении с init-скриптами. systemd исходит из того, что человек, использующий его, обязан вникать в его «идеологию» и конфигурацию, чтобы systemd ему ничего не ломал.
(это примерно как в кейсе взаимного влияния iptables + docker + scm + vpn)
По вашей ссылке:
I don't use systemd, what does this mean for me?
Nothing. This page is about systemd's cgroups APIs.
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.
Мне не важно сколько займет перезагрузка моего сервера в продакшене, он далеко не каждый день перезагружается.а вот у других контейнеры стартуют тысячами. и системд отлично работает в обоих случаях.
А вот понимание системы инициализации и возможность починить ее мне важна. systemd это черный ящикпотому что после изучения шелла теряется способность читать маны?
а вот у других контейнеры стартуют тысячами. и системд отлично работает в обоих случаях.
Я не понимаю как это связано с тем, что я сказал выше, но это не важно, потому что...
потому что после изучения шелла теряется способность читать маны?
… вы скатываетесь в хамство и вести дальнейшую дискуссию с вами я смысла не вижу.
Трагедия systemd