что получится при реализации journald + PostgreSQL

Давай я процитирую твой вывод, о том что получится при реализации journald + PostgreSQL:

Теперь у нас получится простая картинка. journald будет чего-то там на сервере «агрегировать», пулять всё сагрегированное в syslog, а тот уже по старинке, по UDP/514 — прямиком на сервер логов, где они и будут обрабатываться.

И при чём тут PostgreSQL и почему ты называеш её journald + postgresql а не journald + syslog, я даже не буду спрашивать. Ты может SEO-шник, чем больше ключевых слов в текст проставишь, тем больше заплатят.

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

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

Последние оплоты борьбы с systemd — слакварь, Gentoo и Dragora.

Это должно воодушевлять?.. Кстати, есть еще crux, пакетов правда, даже с учетом пользовательских мало, зато позиция (пока?) чоткая.

Вотэто счастьё))

На опенке видал новость корректнее, да 16.04 еще не скоро))

Тьфы ты блин. journald хотел сказать.

Можно ссылочку на commit, просто интересно.

Народ, а что посоветуете для изучения systemd? Есть какие-нить хэндбуки, или какие-то языки сверху внимать надо?

R.I.P.

Хотите, чтобы ваши темы пользовались популярностью на ЛОР'е и набирали много постов укажите в них два слова «Ubuntu» и «systemd» (с)

Цитировать надо...

... полностью. Тогда не будет лишних вопросов и попыток передёрнуть. Итак:

Итак, начнём с того, что я ни фига не просто так задал свой вопрос про journald + PostgreSQL. Вообще-то, дело в том, что до того, как его задавать я тестировал данную связку, правда и давненько уже. Но не страшно.

На данный момент, предположим есть просто сервер, не один, не два, много. Эти сервера сливают по UDP/514, по syslog логи на удалённый сервер логов. Мне будет сложно объяснить почему там у меня syslog с добавлениями (пре-аналитика, вывод алармов на консоли операторов, ... PostgreSQL). Решение довольно давнее и довольно специфичное. Пусть будет rsyslog, это не существенно.

Теперь у нас получится простая картинка. journald будет чего-то там на сервере «агрегировать», пулять всё сагрегированное в syslog, а тот уже по старинке, по UDP/514 — прямиком на сервер логов, где они и будут обрабатываться. Вот что у нас получится. Вот и вся Ваша «связка».

Семантика какого абзаца в данном случае Вам не понятна?

И при чём тут PostgreSQL и почему ты называеш её journald + postgresql а не journald + syslog, я даже не буду спрашивать.

Немного поёрничаю. ;) Меня тут анонимус в чём-то пытался обвинить... Теперь сижу и думаю — может он промазал? :)

Вот только в чём незадача. Дело в том, что:

И что она никак не оправдывает и не доказывает полезность самого по себе journald

Я поправил Вашу цитату. При таком раскладе journald есть дополнительная сущность. Собственно, я уже говорил, но повторюсь — «выгода сомнительна, а вот вред очевиден». Это лишний (дополнительный) софт, а в Gentoo его не особо приветствуют, как надеюсь всем известно. Это лишние конфиги, которые надо не забыть поправить. Короче, man «Бритва Оккама». И всё только потому, что одному оленю тупорылому стрельнуло в башку что проверенные методы работы с логами ему показались староватыми.

Больше скажу! Если бы в самом systemd был использован стандартный вариант с syslog.h (учитывая то, что сырцы всё-таки на С, пусть и скверном С, но всё же), то я бы лично по данному вопросу и не возникал. Говорят что она загружается быстрее? Ну и хорошо. И фиг бы с ней, в конце-концов, видели и не такое. Переживём. Но система инициализации, которая делает ещё чёрт знает сколько, окромя самой инициализации (по слухам её даже минетом можно озадачить при случае или за кофейком сгонять), ну это уже просто перебор.

Если можно, ...

...то без обид, хорошо? Просто подкалываем, без злости. :)

/* А могли бы порекомендовать попользоваться жидким азотом для охлаждения сопла... А то таким макаром Марк так убунтовцев затроллит, что они на реактивную тягу перейдут... :) */

как неожиданно...

Юбунта - торт!

Сюда...

... -> http://www.freedesktop.org/wiki/Software/systemd/

Раздел «Manuals and Documentation for Users and Administrators». Важнее всего маны (сразу поймёте всю... ага... «простоту» системы), ну и типсы с триксами. Да, в принципе, там весь раздел надо смотреть.

Вообще-то модульность кода - это одно, а независимое версионирование всех компонентов - другое.

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

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

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

Почитай что-нибудь по SE, а то от твоих постов на эту тему сплошной фейспалм (/me .oO( хорошая метка, кстати))

Одобряемс. Если они еще и mir закопают то я даже начну думать, что ubuntu не такая уж и ненужная.

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

ну я же говорю истерика ради истерики.

Квадратики в консоли на intel-драйверах уже пофиксили, или всё также через udev?

Народ, а что посоветуете для изучения systemd? Есть какие-нить хэндбуки, или какие-то языки сверху внимать надо?

Если для администрирования, то надо взглянуть на статьи «Systemd for administrators» (первая тут, ссылки на всю серию тут).

видеокарта какая?

дубль 100500

Чего плохого в системд? Софт или железо неработает?

То что его сделал поцтеринг, ответ не принимается.

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

Dragora

Это хто? :)

Конечно иногда вылазят косяки, но это явно из-за недостатка тестирования и молодости проекта.

Проекту уже 4 года. Нужно ждать совершеннолетия?

по существу никто ничего предъявить не смог

Невозможно ничего по существу предъявить тем, у кого главный аргумент - «УМВР».

• «Стандарт» через реализацию.
• Тащит некоторые высокоуровневые вещи на низкий уровень (нарушение иерархии абстракций что ли).
• Переключает на себя избыточно много контроля: подключается «сверху» там, где можно «сбоку» или «снизу».
• Возможно неоправданно много гвоздей (linux-only например).
• Просто субъективно неприятно, что его навязывают.

Братишка, я тебе систему инициализации принес..

http://www.dragora.org/en/index.html

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

«Фелкер выделяет три основные архитектурные проблемы systemd:

В Unix-системах PID 1 имеет специальное назначение, в частности, PID 1 становится родителем для осиротевших процессов и поддерживает специальную семантику сигналов. В случае краха обработчика PID 1, происходит крах всей системы (kernel panic). Традиционные системы инициализации минимизируют размер кода и число функций обработчика PID 1, в то время как systemd выносит на уровень PID 1 серию демонов, реализующих вторичные функции, что приводит к общему снижению надёжности. Если традиционный init-процесс занимается лишь обработкой сигнала SIGCHLD от осиротевших процессов и реагирует на смену администратором текущего уровня запуска (runlevel), то systemd дополнительно занимается такими вещами, как управление подключением и отключением устройств, изменением точек монтирования, слежение за состоянием элементов в ФС и даже обработка запросов через DBus API.

В защищённой системе без systemd, обычно присутствует только один привилегированный процесс, критичный для проведения атаки, - sshd. Все остальные компоненты управляются и получают входные данные только от пользователя root. В случае systemd присутствуют каналы взаимодействия с непривилегированным пользователем. Реализация расширенных функций в systemd приводит к необходимости выполнения на привилегированном уровне лишнего кода по выделению ресурсов, обработки файлов, разбору сообщений и обработке строковых данных, что увеличивает риск возникновения уязвимостей, которые могут быть эксплуатированы непривилегированным пользователем.

Вынос на уровень системы инициализации дополнительных функций приводит к необходимости перезагрузки системы при установке обновлений компонентов systemd, обеспечивающих работу PID 1.»

С opennet.

Ну и до кучи нарушение принципов unixway:

• Small is beautiful.
• Make each program do one thing well.
• Build a prototype as soon as possible.
• Choose portability over efficiency.
• Store data in flat text files.
• Use software leverage to your advantage.
• Use shell scripts to increase leverage and portability.
• Avoid captive user interfaces.
• Make every program a filter.

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

По-русски нашёл на опеннете. :)

Говно какое-то

а чем оно так плохо?

Вот почему-то мне кажется, что слака этим же путём пойдёт.

Кружевные трусы

Это разве драма! Вот таможенный союз, Россия, Беларусь, Казахстан, запретил ввоз кружевных трусов, вот это драма!

интегрированная интел

запретил ввоз кружевных трусов

срочно на главную!

не раскачивай лодку ;)

В общем странно, у меня на probook 430 из коробки не работает, приходится через udev.

Говно какое-то

Зато полностью свободное и без душного systemd!!11 Ты не понимаешь и не поймешь* !!!111

*и это хорошо

Ну и хорошо, давно пора. Upstart - это хорошо, но systemd все же лучше.

Если они еще и mir закопают то я даже начну думать, что ubuntu не такая уж и ненужная

Останется один шаг - закопать unity и будет отличный дистрибутив.

так мы ж совсем недавно на апстарт перешли!

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

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

Но с другой стороны, если этого не делать - будешь всегда сидеть как ретроград, со старьем. И это тоже нехорошо.

Спасибо, незнакомый друг, за своевременное обращение к классике!

plm
значит RHEL6 был фейлом? как ты это переживешь? он у стольких людей установлен... просто не верится...
может в честь этого revelation'а (пусть и крайне неприятного), вы там выкинете своё мертворожденное поделие? well, asking too much, я знаю, но может хотя бы блевотный артворк под «замороженную хахламу» уберёте. хотя, после этого отличий от ваниллы совсем мало станет. пичалька, хнык.

Почему RHEL6 фейл? На тот момент Upstart был лучшей альтернативой и хорошо послужил, а потом его сменило более подходящее решение. Всего лишь эволюция

ну вот, всю малину испортил.

rip Ubuntu!!! пока!

Шах и мат.