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

Вот я и выясню, хотя бы для одного только себя, является ли ненависть systemd-хейтеров обоснованной недостатками systemd или же просто их фанатизмом. Лично для меня systemd не является объектом ненависти, но содержит принципиальные недостатки. Поэтому я готов к мужскому разговору с ним... Ну, на ЛОРе, конечно.

Бинарные же не конфиги, а логи?

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

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

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

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

В данном случае мы имеем расширенные, но нечитаемые без лишних утилит журналы. Получить должны... Стоит ли вообще заморачиваться с изменением или переписыванием способов ведения журналов systemd?

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

ну плюсы текстового журнала я могу понять, это и например легкость его прочтения с помощью того же cat или less. особенно это критично при непредвиденных падениях системы(отказ железа илиеще чего), но и в том что это можно сделать и из лайв системы с наличием того же systemd-jurnal на борту тоже проблем быть не должно. но согласен что уходить далеко от текстового формата как конфигов , так и логов это не есть супер. в остальном ничего плохого не заметил. да есть плюс что не используется баш почти. это снимает повод беспокоиться о дырявости хотя бы тут. остальное думаю нужно жестко тестировать.

да есть плюс что не используется баш почти.

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

остальное думаю нужно жестко тестировать.

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

systemd - универсальное решение, так же? Соответствено и допиливать его нужно так, чтобы устраивало и десктоп и сервера. Юниксвей в данном случае будет не разделение инитов - нагроможденный десктопу и простой серверу - а разеделение systemd на модули, при котором десктоп будет использовать один набор модулей, сервер - другой.

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

А далеко ходить не надо. Не далее чем полгода назад лор падал именно из-за него. Комментарий макскома, дословно: «упал и не поднимался по неизвестной причине.»

и ещё, взгляните на этот захардкоженный пиздец:

http://cgit.freedesktop.org/systemd/systemd/tree/src/core/dbus-manager.c

Давать ссылку на файл в 1739 строк и не указать конкретное место (подсказка: номера строк являются ссылками)... При беглом просмотре ничего ужасного не увидел. Что именно вам так не приглянулось?

Я ~3 года использую Gentoo без initrd. Нужно разве что для какого-нибудь plymouth или hibernate - первый не использую, а для второго есть tuxonice, там инитрд не нужен.

Ты мне напоминаешь Поттеринга, которому про принципы разработки, а он в ответ - «в моих юзкейсах всё и так УМВР, не нужно».

Ты спросил, про initrd, тебе ответили про initrd.

То, что у тебя всё работает, - прекрасно. Но твои полтора юзкейса - это одно, а концепции проектирования - это другое.

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

Можно и разделить. Но нафига? Практического смысла в этом нет, только задрачивание на чистоту архитектуры.

Если тебе так охота, устанавливай подключение, а потом читай-пиши любой утилитой в /proc/<pid>/fd/<номер>. Вот тебе и разделение.

Вторую часть сообщения ты предпочёл не заметить. Ожидаемо.

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

Но собеседник по-прежнему пишет херню про grep.

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

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

Капча callench philosophers как бы символизирует.

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

Представил, сколько классов папета надо будет перелопатить, и стало до невозможности тошно.

А то что сейчас в монге отдельные сборки под debian (sysvinit) и ubuntu (upstart) - это потому что ниасиляторы с кривыми руками?

А то что сейчас в монге отдельные сборки под debian (sysvinit) и ubuntu (upstart) - это потому что ниасиляторы с кривыми руками?

Этого я не знаю, что там в монге в этой. Даже если пакет требовать будет систему инициализации, установка пакета не должна форсировать смену системы инициализации без админа. Я полагаю, что в Debian запакетируют, но жесткую зависимость от какой-то системы инициализации не поставят. Вероятно будет жесткая зависимость от виртуального пакета «какая-то система инициализации». В этом был смысл бюллетеня, который готовил Ian Jackson, но внезапно другой член комитета запустил другое голосвание.

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

Короче - Bdale и Поцеринга пора закапывать.

Копипастами и плагиатом промышляешь? ;)

Так большинство или перевешивание всех в 2 раза?

redgremlin> Для 99% задач хватает.

Для 99% задач локалхоста - несомненно.

alpha> просто как и любое философское понятие unix-way, во-первых, каждый трактует по-своему.

Термин unix-way имеет вполне конкретное значение с конкретными примерами.

alpha> А, во-вторых, непреложной догмой он никогда не был.

Именно поэтому появился Plan9. Но то, что сейчас противопостовляют unix-way и предлагают всякие поцеринги на замену - это ни в какие ворота не лезет.

локалхоста

Это такая мантра, когда сказать уже нечего, но очень хочется? Как раз на локалхосте выгоды journal не столь очевидны — логов мало, критичных сервисов нет етц. Расширенный поиск и фильтрация нужны, в первую очередь, в нагруженном продакшене.

И ещё по поводу «unix-way непреложной догмой никогда не был». UNIX-Way - это не догма, а руководство к действию.

Локалхост - это и есть продакшн, причём временами высоконагруженный. Только локалхост. Что же до целой серверной сети - вокруг journald придётся дофигище костылей понастроить. Почему - читай примеры выше. Этот journald не решает ни одной проблемы, с которыми сталкиваются в тех областях с тем же syslog. Вместо бинаризации логов уместнее было бы сделать вариант, удобно интегрирующийся с БД и не привязывающийся к какому-либо иниту.

redgremlin> Так нахрена гнать через скрипты охрениад ненужных строк, когда можно попросить journalctl выдать тебе сразу всю нужную информацию без всей ненужной?

Эта задача решается с помощью grep. Ты, похоже, не понимаешь, зачем скрипты могут понадобиться при анализе логов.

PaulCarroty> Нет, ты написал, что он может засунуть свое мнение, не я.

Ты вот это написал:

засунь себе в задницу

И ты речь начал вести о засовывании при этом, заостряя внимание этом же внимание. У тебя с головой всё в порядке?

PaulCarroty> они уже внесли рад «хаков-линускизмов», чтобы там работал sysv

Ты читать умеешь?

PaulCarroty> так что внезапно systemd позволяет уменьшить количество костылей.

Читай внимательнее - там куда бОльшие костыли в виде тех же cgroups в Hurd. И не факт, что ещё не придётся добавлять. А то, что в sysv точно уже не нужно добавлять костыли - факт.

PaulCarroty> lol, просто идеальная иллюстрация готовности.

Хочешь сказать, что OpenRC не работает7

Вот и выросло...

... поколение, для которого баш-скрипты сложны.

Мдеее...

О, ужас, ...

... да ладно, на фиг. Я с середины 90-х, с момента выхода «The UNIX haters handbook» об этом только и слышу.

Однако воз и ныне там. «Усовершенствователи всего» странным образом не пониают что конвейеры, пайпы, сокеты это всё средства того самого IPC, которого в unix way «не было».

Вообще-то, если о канонiчном unix way, то лучше бы Вам для начала прочесть http://ru.m.wikipedia.org/wiki/Философия_UNIX А то Вы пытаетесть прицепить к мягкому тёплое. Когда прочтёте, то будет интересно узнать как именно те же shared libs противоречат unix way. И где в unix way запрет на использование IPC?

Угу...

... нужны именно там:

Расширенный поиск и фильтрация нужны, в первую очередь, в нагруженном продакшене.

Только я добавлю что в своё время ажно язычёк для этих целей был написан (пока в glibc не появились средства для работы с регулярками). Тот язычёк perl называется. Если по текстовым логам шариться, то лучше его может быть только С-код с libpcre или glibc regexp'ами. Из-за скорости на действительно больших объёмах.

Но ещё лучше поступающие логи конвертировать в субд и там с ними разбираться. Этот подход реализуем либо надстройками для стандартного syslog, либо rsyslog сам такое умеет. Поиск информации о том или ином событии сводится к банальным select по той или иной таблице. Скорость поиска даже и не обсуждается.

Реализация на основе journald будет выглядеть как АдЪ, треш, угар и содомiя.

Предлагаю...

... замутить на kickstarter проект по сбору денег на физическую нейтрализацию господина Поттеринга. Думаю, денег на оплату работы киллера найдём часа за три-четыре. :)

Когда у тебя тысячи серверов, у тебя CMS, и тебе вообще фиолетово на систему инициализации

а там тысячи строк скриптов поддерживать не надо?

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

ну конечно, ведь сказать вам, коням, нечего.

И как эти логи прочитать из другой системы, если надо будет решить какую-нибудь проблему?

journalctl -D /path/to/saved/logs

$ journalctl
bash: journalctl: команда не найдена

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

Да...

... это не проблема:

Единственная поправка - ничего не мешает монтировать /usr из initramfs. Это не проблема.

Только проблема в другом (на мой взгляд) — с какого перепою система инициализации чего-то там вообще указывает? Что и где должно быть. Это, вообще говоря, не её собачье дело как на хосте организована файловая система.

В данном случае показателен подход «товарищей» из АНБ, создавших SELinux. Да, нужен каталог. Один. Он расположен на рутовом разделе. Что мешало Поттерингу со товарищи сделать каталог в рутовом разделе и творить там свои чудеса мне не ясно. Вот и получается — АНБшники да, профи. А этот ваш Поттеринг — чудотвор кухонный.

Зачем...

... их там поддерживать:

а там тысячи строк скриптов поддерживать не надо?

Они великолепно поддерживаются мейнтейнерами. Если вносились какие-то серьёзные изменения, то проще использовать gentoo way (я про configure protect), по крайней мере, это позволяет не терять функциональность при апдейте. Но и то, если команда, обслуживающая инфраструктуру настолько лоси, что накатывают апдейты без предварительного тестирования на стенде.

Но ещё лучше поступающие логи конвертировать в субд и там с ними разбираться.

и вот же чудо из чудес, именно этим занимается journald.

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

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

Оемае, ну ты блин тугой... В Debian есть Pulse Ausio, но по умолчанию Alsa. Ферштейн?

Мне сложно сказать...

... почему:

самый популярный баг - рейс между модулями сетевых карт и сетевым сервисом.

Эти «одмины» настолько олени, что собирают ядра для системы без компиляции того, что априорно есть на данном сервере в ядро по-жёсткому. У них что, есть смутная надежда на хот-свап рейдов или сетевых карт? Если нет, то почему не вкомпилировать потребные модули в ядро и избежать проблем?

ответил тебе анонимом вчера. про отличие принципов от технологии.

Они великолепно поддерживаются мейнтейнерами.

строки в паппете или шефе? RLY?

Если вносились какие-то серьёзные изменения, то проще использовать gentoo way (я про configure protect), по крайней мере, это позволяет не терять функциональность при апдейте.

ох Мойша, кому вы таки впариваете? Какой нормальный админ вообще подумает про генту на сервере? есть только один «way» - проверять апдейты на тестовом стенде, все остальное - не в наших палестинах.

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

Эти «одмины» настолько олени, что собирают ядра для системы без компиляции того, что априорно есть на данном сервере в ядро по-жёсткому. У них что, есть смутная надежда на хот-свап рейдов или сетевых карт? Если нет, то почему не вкомпилировать потребные модули в ядро и избежать проблем?

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

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

Да вот...

... на фиг такие «чудеса»:

и вот же чудо из чудес, именно этим занимается journald

Прошу показать как именно journald может конвертировать логи в PostgreSQL.

Если интересно, то посмотрите как это же делает rsyslog (например).

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

Что, простите? Вы сейчас о чём? О... логах? Вот как-то последние лет 30 со структурированностью проблем не было. Но появился Поттеринг и проблемы появились. Не?

Вопрос о том, зачем что-то выгружать, если логи по своей сути и так структурироанная информация в текстовом виде, уже пригодная к поиску информации о событии, я не задаю. Более того, в системе сразу есть интерфейс для syslog. Меня, как C-программиста всегда чертовски радует syslog.h (считайте это тонким намёком).

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

Правило модульности: Пишите простые части, соединяемые понятными интерфейсами.
Правило ясности: Ясность лучше заумности.
Правило композиции: Разрабатывайте программы так, чтобы их можно было соединить с другими программами.
Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine).
Правило простоты: Нацельтесь на простоту; добавляйте сложность, только где необходимо.
Правило экономности: Пишите большую программу только когда другими средствами выполнить необходимую задачу не удастся.
Правило прозрачности: Разрабатывайте прозрачные программы для облегчения последующего пересмотра и отладки.
Правило надёжности: Надёжность — дитя прозрачности и простоты.
Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной.
Правило наименьшего удивления: При разработке интерфейса всегда делайте как можно меньше неожиданных вещей.
Правило тишины: Если программе нечего сказать, пусть лучше молчит.
Правило восстановления: Если надо выйти из строя, делайте это шумно и как можно быстрее.
Правило экономии: Время программиста дорого; сократите его, используя машинное время.
Правило генерации: Избегайте ручного набора кода; при любом удобном случае пишите программы, которые бы писали программы.
Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте.
Правило многообразия: Отвергайте все утверждения об «единственно правильном пути».
Правило расширяемости: Разрабатывайте для будущего. Оно наступит быстрее, чем вы думаете.

Пожалуй, придется возвращаться на Slackware. Или попробовать Gentoo.

а там тысячи строк скриптов поддерживать не надо?

там они поддерживаются ровно один раз

ну конечно, ведь сказать вам, коням, нечего

ок, давай подробно по каждому пункту, с примерами из реальной жизни

Кто запрещает тебе юзать syslog? Нужен этот комбайн, так запускай и извращайся с логами как тебе угодно, если так привычно. Никто возможности запускать syslog не запрещал, так же как и обычные портянки инита. А фанатики, они в основном как раз и против systemd, ибо принцип «не читал, но осуждаю» никто не отменял.

там они поддерживаются ровно один раз

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

ок, давай подробно по каждому пункту, с примерами из реальной жизни

а что не было понятно с самого начала?

Таки мы не на Привозе...

... чтобы я Вам таки уже чтой-то впаривал:

Какой нормальный админ вообще подумает про генту на сервере? есть только один «way» - проверять апдейты на тестовом стенде, все остальное - не в наших палестинах

Тот, которому платят за это денег. И уж явно не тот, который намедни открыл для себя Spacewalk от RedHat, благодаря которому (о, чудо!) он может намазывать «крававай ынтырпрайз» не думая о последствиях такого «намазывания». Оно понятно, что вас, богатых, не поймёшь, но лично для меня («меня» здесь не просто фигуральный оборот, я совладелец бизнеса и, по совместительству, генеральный) ~22% производительности, это более чем дофига. http://software.intel.com/en-us/blogs/2012/09/26/gcc-x86-performance-hints (смотрим на -m64 -Ofast -flto -march=native -funroll-loops и вкуриваем нужность и православность Gentoo).

Да. Именно. На стенде. Только вот кейсы будут малость разные. Для HP DL-380 один, а для HP DL-980 слегка другой. Сборки так же разные. А далее уже bindist хорошо помогает.

то сколько времени уйдет только на то чтоб получить всю эту инфу в читабельном виде?

Время выполнения select в PostgreSQL. Внезапно, но так. Это есть, сделано, уже работает. Читабельных видов несколько, в том числе и синоптическтий отчёт по отказам сети в libreoffice. Кстати, там не только данные от «серверов», там же данные от всякого сетевого инфраструктурного оборудования. Циски-джуниперы-всякий треш.

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

по делу есть что сказать?

а что не было понятно с самого начала?

весь тот бред, что ты написал. Давай примеры гонок, проблем с sysvinit на «нестандартном железе» и прочего.