systemd, upstart (ничего не путаю?), почему массы негодуют?

А тебя Яровая покусала? Мое резюме с текущим и прошлым местами работы опубликовано.

Раз уж ты спросил, то я был на последнем семинаре RedHat, где хорошо поел и обрел пару ручек и молескин с логотипом. Ну и послушал, зачем и кому этот systemd нужен и что с виртуализацией происходит, где там место RedHat.

Я не защищаю RedHat или systemd, отнюдь нет. К systemd у меня тоже есть вопросы.

Alsvartr> Ну, есть еще апстарт, openrc и кучка красноглазых инитов для наркоманов. Кроме апстарта тут рассматривать нечего.

Начнём с того, что разберёмся в возможностях systemd возложенных на него задачах. И аналогично sysvinit.

Задачи sysvinit (вместе с sysv-rc): инициализация, запуск и остановка сервисов. Грубо говоря, конечно.

Теперь systemd: инициализация, запуск и остановка сервисов, service supervision, ведение логов, управление сессиями, и ещё много чего другого (перечислил самое, так сказать, популярное).

У upstart схожие с systemd задачи, но отсутствуют такие штуковины как логгирование, вебсервер, генератор qr-кодов и т.п. (потихоньку это исправляют - см. портирование logind на upstart).

systemd и upstart выполняют функции sysvinit. OpenRC их не выполняет - у него просто нет таких возможностей. Он дополняет init.

Что в итоге имеем: два монстра, которые написаны эталонными быдлокодерами, имеющие адски раздутую кодовую базу и не имеющие адекватной архитектуры (systemd и upstart), есть отдельные иниты (System V Init, BSD Init, initng, minit, ...), есть OpenRC, значительно расширяющий возможности управления сервисами (выделю OpenRC отдельно как особый случай), но не заменяющий инит, есть специализированные системы service supervision (s6, runit, daemon tools, perp, ...), некоторые из которых могут также заменять init. И это вовсе не красноглазые наркоманские иниты (о существовании которых ты наверняка и не подозреваешь). О положении дел в других ОС уж не буду рассказывать.

А теперь вопрос: какого хрена?

А тебя Яровая покусала?

Кто? Какая-такая Яровая-Озимая?

Мое резюме с текущим и прошлым местами работы опубликовано.

Ты думаешь я по всему ЛОРу шукаю? Ты хотя бы на мой список игнорированных тегов посмотри!

где там место RedHat

Шапка уже давно скатилась. А ведь когда-то хороший дистрибутив был!

лапша шелл скриптов с тоннами дублирующего функционала

Чем это отличается от лапши ини файлов с тоннами все тех же шелл скриптов сразу посля слов «Exec*=» и тому подобных деректив?
Что меняется? Ни-че-го. Просто еще один, другой, синтаксис, который лишает тебя возможности гибко кастомизировать ЗАПУСК сервиса. Для эндюзера - неважно. Для знающего - мудотень.

Нет слежения за состоянием сервисов

Это не есть задача системы ИНИЦИАЛИЗАЦИИ(!), равно как и логирование, дбас сервис, демон полиси, удев и т.д.

По умолчанию ли?

ворованный UNIX

Это что такое и в каком году? BSDi или SCO? Solaris для х86 тогда уже бесплатный вроде был.

Да.

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

И частный вопрос: если архитектура у предлагаемого решения дефективна (на самом деле это исправляется парой костылей и сменой подхода разработки в случае systemd, но Поттерингу пофиг), зачем его тащить по умолчанию?

Касательно сетевых аспектов

не успевает упасть на диск

читай на что отвечаешь.

Ну а вообще конечно видел. Но решается это уж точно не заменой системы инициализации :-) траст ми :-)

ключевое слово «будет». Но пока что нет. А значит нот реди :-)

Суть проблемы много раз расписывали. Но тебе, видимо, насрать.

А в чем дефектность архитектуры systemd (not irony, у меня пока все на SystemV, systemd только смотрел и 1 раз не осилил его связать с XBMC).

Так и systemd не только система инициализации.

Думаешь, помню? Я ж не про себя, а про местный народ. Сам я линуксом вплотную года с 2003-2004-го занялся. Здесь, насколько помню, до того, как кто-то привез ворованную "шапку" (потом она понравилась, и народ из командировок стал возить диски с обновлениями), были поклонники разных юниксов. Точно вспомнить, что там было, они и сами уже, пожалуй, вряд ли смогут.

Вот солярку помню: даже ставить ее пытался году в 2002.

Я не понял сути твоего вопроса.

читай на что отвечаешь

тем более пролезть в сеть.

Доступна бета-версия Red Hat Enterprise Linux 7

Основная моя претензия к текущим инитам в том, что они неунифицированы и непредсказуемы в поведении, в отличие от systemd.
Более развернутый вариант писал dyasny, я с ним полностью согласен.

Вот это недавний пост одного товарища в G+-ленте

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

А ещё когда процесс /etc/init.d/<service> start получает переменные окружения того, кто выполнил эту команду из-под sudo — это не радостно.

Я щас тебе другое скажу, sudo rm -rf /* приводит к куда более плачевным последствиям. Я это к чему, к тому что ошибки администрирования - это просто ошибки, и инит их не исправит.
И кстати конкретно в твоем примере ложь, т.к. по умолчанию юзер энв резетится во время сюдо, а то о чем ты говоришь достигается ключиком у сюды - sudo -E

Скорость на запись класного удачного САТА винта примерно 50МБ/с -> 400Mbit/s. В нынешних реалиях скорость сети в 2,5 раза выше... О чем ты?

класного удачного САТА винта примерно 50МБ/с

Ты единичку потерял.
ST2000DM003, нифига не быстрый сата-винт, на записи выдает порядка 120МБ/сек.

И это при том, что такие проблемы решаются в рамках системы service supervision, которая отдельно от инита может работать.

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

проблемы зомби это проблемы зомби.

Проблемы управления сервисами - это проблемы управления сервисами.

И кстати конкретно в твоем примере ложь

Не надо путать ложь и ошибку. Не «sudo», а «su -c», да.

А теперь вопрос: какого хрена?

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

*красноглазо так* вот это и ужасно.

А когда этот RHEL7 выйдет?

Вроде как во втором квартале.

Чем это отличается от лапши ини файлов с тоннами все тех же шелл скриптов сразу посля слов «Exec*=» и тому подобных деректив?

Правильно выше сказали. Посмотри иниты чуть дальше старт/стоп/статус. Юниты системд по сравнению с этим средневековым мракобесием - просто глоток воздуха.

Это не есть задача системы ИНИЦИАЛИЗАЦИИ(!), равно как и логирование, дбас сервис, демон полиси, удев и т.д.

Строго пофиг, чья это задача. Смысл делать это в ините я писал, кстати, выше.

Он берёт на себя задачу инита и, не разграничивая функциональность, фактически в pid 1 тащит то, чему там противопоказано быть. Подробнее (не по всем аспектам, но для начала достаточно) тут: http://ewontfix.com/14/

Более развернутый вариант писал dyasny, я с ним полностью согласен.

Кстати, да. Он очень здраво все расписал.

Systemd тоже из этих неунифицированных инитов. 10 конкурирующих стандартов, добавляем новый для покрытия всего и получаем 11 конкурирующих - не видел что-ли тот стрип?

jet@earth:~$ dmesg | grep ata.*ST
[    1.185195] ata1.00: ATA-8: ST31000524AS, JC4B, max UDMA/133
[    1.504607] ata2.00: ATA-9: ST1000DM003-1CH162, CC47, max UDMA/133
jet@earth:~$ cat /proc/mdstat | grep md2
md2 : active raid1 sda2[2] sdb2[1]
jet@earth:~$ dd if=/dev/zero of=./file bs=1024 count=1024000
1024000+0 записів прочитано
1024000+0 записів записано
скопійовано 1048576000 байтів (1,0 GB), 15,7887 с, 66,4 MB/s

Да что вы говорите?

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

Эти монстры - это просто одни из вариантов решения. А разговоры про архитектуру в данном случае имеют серьёзные основния для всех. Проблема в том, что и без этой интеграции в большую жопу практически всё то же самое можно делать с уже написанными решениями и объединить их в одно адекватное. Но нет! Не хотит грамотных решений с той же функциональностью и большей гибкостью и надёжностью! Хотим жрать апстарт и системдэ!

Проблемы управления сервисами - это проблемы управления сервисами.

Действительно, когда нечего аргументированно ответить, можно просто скопипастить фразу оторвав от контекста и рандомно ответить. ГФ

Не надо путать ложь и ошибку. Не «sudo», а «su -c», да.

Ты пользуешься «su -c»? У тебя есть пароль у рута? Тогда нечего тут продолжать дискуссию как если мы типа крутые спецы.

Будет интересно посмотреть, что в итоге выйдет.

Я лично не вижу, чем systemd так плох. Переход с sysvinit на systemd оставил у меня положительные впечатления. systemctl из systemd намного удобнее и даже чуть понятнее чем этот ваш sysvinit. И работает быстрее, а это уже большой плюс.

Вообщем, особых минусов в systemd я не вижу(кроме жёстких зависимостей с udev), хотя я и не особо в нём разбирался. Если кто-то подскажет, чем же так плох systemd, я с благодарностью выслушаю.

Моё текущее мнение состоит в том, что ненависть к systemd это осадок после pulseaudio(который должен умереть), плюс жёсткие зависимости с udev.

Может и здраво, но однобоко.

Systemd тоже из этих неунифицированных инитов

Как раз таки нет.
В systemd всё унифицировано настолько, насколько это технически оправдано.

Да что вы говорите?
bs=1024

апстену - это там.
где bs=1M?

Посмотри иниты чуть дальше старт/стоп/статус. Юниты системд по сравнению с этим средневековым мракобесием - просто глоток воздуха.

Правда в том что юниты системд просто не умеют столько сколька это самое шеловое мракобесие. Чисто для себя, просто сравнени инит ШС и юнит Апача, и почуствую разницу в функционале(Подсказка: юнит это просто врапер над апачктл -к старт/стоп). Впрочем если для тебя примитивный шел скрипт - мракобесие, то я бы посоветовал воспользоваться графическим интерфейсом настройки. Т.к. юниты та же фигня. Да и кроме юнитов в любом дистро тонны шелскрипта.

Строго пофиг, чья это задача. Смысл делать это в ините я писал, кстати, выше.

Если пофиг - есть Windows, и он справляется с этим лучше, да и в администрировании проще...

jet@earth:~$ fdisk -l /dev/sda | grep Sector\ size
Sector size (logical/physical): 512 bytes / 512 bytes

Теоретек?

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

Т.е. ты не понимаешь, что винту просто не хватает производительности по IOPS, чтобы bs=1K показал его реальную скорость? Да ты упоролся :-D
BTW, все винты этой серии - AF.

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

Действительно, когда нечего аргументированно ответить

Ты спрашивал примеры «хреновой работы» — так это был один из них. Ты его отмел как несущественный - так проехали, что тут ещё аргументировать.

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

Ты спрашивал примеры «хреновой работы» — так это был один из них. Ты его отмел как несущественный - так проехали, что тут ещё аргументировать.

Ну да, потому что вачдог это не часть инита, и не должна(не только по моему мнению) ею быть. То что это есть в системд может быть в тех или иных случаях и правда плюсом. Однако её отсутствие, в том месте где его не должно быть, не может быть минусом. Вот такой мой ход мыслей.

Не пофигу, шлю, а умники типа тебя идут нахрен. Я серьёзно мнения типа «если не делаете, то и не вякайте», заслуживают ещё меньшего внимание, чем рытье, тьфу!

Энв обнуляется, если чо.

Те кому не надо грепать логи используют БД и соотв системы обработки логов.

Убивать все сервисы научить инит дело двух дней (после чего патчи лежат в апстриме и всем достаточно 1 строке в конфиге)

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

Энв обнуляется, если чо.

Кем именно?

Те кому не надо грепать логи используют БД и соотв системы обработки логов.

В идеальном мире - возможно да. А в реальном - всё несколько иначе и сильно зависит от масштабов инфраструктуры и людей задействованных в её обслуживании.

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

Убивать все сервисы научить инит дело двух дней

А этот аргумент мне больше всего нравится. Главное что я верю, что всё можно сделать. Вопрос только кто это будет делать, когда, почему не сделал до сих пор и сколько нам ещё ждать пока он доведёт то, что делает, до production-ready версии.

Кем именно?

Скриптами, не знаю как в дебьянах (там грузятся доп скрипты перед загрузкой инита, где env успешно чистится), аналогично в openrc, там runscript использует абсолютные пути для запуска компонент и фильтрует env, если нужно переменные пропускать, то нужно в конф файле явно задавать white list.

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

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

Я правильно понял, что логи в raw виде попадали в БД, а интересные парсились и писались в специализированные таблицы?

Вопрос только кто это будет делать,

Напр. я

когда,

Год назад

почему не сделал до сих пор

Не знаю даже, что и ответить. Разве что, а не напрягает, что именно эта часть делает системд линукс онли?

и сколько нам ещё ждать пока он доведёт то, что делает, до production-ready версии.

Вам ждать этого не нужно, т.к. опенрц, к сожалению фаворитом не будет, если только чудо не случится, а так оно в 0.12 в Генте, некритичные баги были, часть исправлено, часть вскоре будет. Основная проблема, что я этим занимаюсь где-то час в месяц и в том что изменения медленно проверяются главным разработчиком..