Пожалуй, ...

... открою секрет:

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

Оггада... Конечно. :) Процесс «компиляции ядра» в самом простом случае (если не появилось каких-то радикальных нововведений) сводится к копированию .config из каталога со старым ядром в новый, далее запуску make menuconfig, сохранение результатов. Если были радикальные изменения, то правка, само собой, последняя такая масштабная правка была с введение cgroups, по мелочи подправляем изредка. Далее просто make. Для сервера всё-таки лучше без модулей, ибо конфигурация там не меняется годами. Проверяется (да, на стенде), там же делается package, который bindist'ом педалится на все подчинённые сервера, для которых это ядро собрано (нет, на 380 и 980 ядра разные по функционалу, но не по версии). Всё.

Да, это несколько сложнее, чем подход RH, в которой для CentOS 6.5 (January 15, 2014) предлагается, ЕМНИП, kernel-2.6.32-431. Простите, это такая «стабильность» или это уже «археология» из разряда «археологи RH открыли новое ядро — 2.6.32, находящееся в культурном слое где-то неподалёку от овна мамонта». Победа... Epic win, слов нет. :)

Там ссылка на первоисточник есть.

тоесть перевешивание в x раз это не большинство?

Зачем? Ну вот зачем так делать? Придется Xen-сервера на Gentoo переводить =(. Я хоть Gentoo и люблю, но дебиан все же более подходил для продакшна =(.

Вообще наблюдаю повальную тенденцию к проталкиванию г**на во всех отраслях и это грустно =(. Нахрена насильно пересаживать на эту недокументированную и неудобную гадость? Как теперь скрипты логи будут писать? Надо будет отдельную софтину для чтения логов делать? И доколе будем сущности плодить?

А deb2rpm уже есть в стандартных утилитах на Debian?

смешно то, что journald позволяет из вращаться с grep&see, но анонимус об этом стыдливо умолчал.

Ну... ты настраиваешь сислог, который дампит сообщения в journald :D Зачем заниматься подобными вещами — загадка.

ничего я не заострял, просто обратил внимание на твою глупую лексику.да, с чего ты взял что в sysv не надо больше костылей? для systemd упоминается только cgroups.что касается openrc, то назвать это стабильной работой нельзя никак.

чет я продолбал голосования все, все без меня прошло.

То есть главная проблема дебиана - это лично ты! :)

не смог пройти мимо...

Ядро, которое сейчас в EL6 (2.6.32-431 или какое оно там) - по функционалу на уровне ~ 3.5.х ядер

// i_gnatenko_brain

по-видимому проблема не в выборе между upstart и systemd. Это ложная дилемма.
проблема в философской плоскости и методах работы которые разламывают коллектив.

Ну, не знаю...

... я функционал не сравнивал. Мне и на 3.* вполне неплохо.

Прочитал новость. Снес Debian, поставил Ubuntu 12.04.4 LTS. Debian, давай до свидания. Предвосхищая вопросы, да если Ubuntu перейдёт вслед за Debian, то уйду ещё куда. Если не останется дистрибутивов без systemd, уйду на FreeBSD.

Вам c Tribunal надо сразу с публикации резюме начинать.

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

А какой метод в данной ситуации не разломал бы коллектив?

А можно...

... попросить вести дискуссию в рамках задаваемых вопросов (например)? Вот там про взаимодействие journald с PostgreSQL вопрос был...

А то люди, точно знающие что и кому надо делать, но при этом выдающие ноль пинформации по теме, вызывают острое желание указать им направление. Я... понятно объясняю?

Непонял, при чем тут пайпы? Если ты про представление файлового интерфейса то абстрагировать можно хоть два пайпа, хоть один, не вижу проблемы.

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

Чтобы иметь общий файловый интерфейс, а с файлами сегодня можно делать все что угодно, начиная от работы в консоли с элементарными cat и echo, заканчивая расшариванием его по сети.

Отметился последний голосующий Andreas Barth - https://lists.debian.org/debian-ctte/2014/02/msg00398.html

Его вариант: U, F, D, O, V. Первым апстарт, вторым дальнейшее обсуждение, третьим - systemd.

Если кто понимает, как ведется подсчет голосов, поясните итог, плз.

проблема в философской плоскости и методах работы которые разламывают коллектив.

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

и методах работы которые разламывают коллектив.

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

тебе не нужно, оставайся на винде

Так и знал что ты с пунктом превращения линуха в винду не будешь спорить. Ну спасибо за признание что ты здесь работаешь на подсосе этаким Балмером от редхета.

1700 строк. Камменты? Не, не слышали.

чем больше в коде коментов тем больше там хаков и костылей

чем больше в коде коментов тем больше там хаков и костылей

И то верно. Откуда ж взяться хакам и костылям во write-only коде, в котором уже через пару недель сам автор без поллитры не разберётся?

А, понял. Просто таким макаром получится, что для работоспособности все демоны должны будут тащить скрипты для ((systemd + upstart) или sysvinit). Aдъ :)

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

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

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

Чудо из чудес заключается в том, что все эти задачи решались ДО journald.

Я смотрю, у федороводов реально избирательная слепота. То, что логи логично писать в буду они видят. То, что бинарные логи journald - это дефакто-то и есть БД они тоже видят. А то, что это кривая беспомощная поделка с нестабильным и де-факто проприетарным форматом хранилища («не читайте наше хранилище своим собственным кодом, мы можем изменить формат вы любой момент!») пытается решать задачу, которая давно и успешно решена при помощи syslog + любая промышленная СУБД (как минимум, постгре, мускуль, на выбор) - этого они в упор не замечают.

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

Что за бред? Ты предлагаешь на один процесс одну ОС выделять и тотальную бинаризацию делать? Нет, спасибо, кушай сам.

Вот только не факт, что одна версия journalctl сможет читать файлы другой версии.

И все-таки вопрос к админам серверов, желательно очень большого количества и с высокими нагрузками, именно на Debian. Используете ли вы systemd сейчас (это же уже давно можно, только не по умолчанию) и если да, то какие плюсы и минусы есть? Всякая ересь типа «времени загрузки» не в счет, ибо сервера, работающие долго без перезагрузки.

Помнится Патрик высказывался против systemd.

У патрика вообще BSD init. Там даже до SysV как до марса

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

Никто не запрещает. Дома у меня крутится journald, потому как пофиг. А там где надо нормальный «комбайн», там, соответственно, journald не крутится.

Я не против journald, я против идиотского пиара journald как журнала промышленного уровня. Эта поделка годится для локалхоста дяди Васи, не более.

Ты предлагаешь на один процесс одну ОС выделять и тотальную бинаризацию делать?

Я не знаю сколько и чего надо употребить, чтобы увидеть там это. Завязывай с этой дрянью, переходи на ЛСД хотя бы, там глюки не такие глобальные.

dyasny> Когда CTO Боинга или Эксон-Мобил говорит что они тратят слишком много времени на допиливание, это не звучит как мяуканье :)

С systemd они ничего не будут допиливать? Или systemd под них пилится специально? А если требования у других совершенно другие? Держать свою ветку systemd?

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

Во. Дело говоришь!

смешно то, что journald позволяет из вращаться с grep&see, но анонимус об этом стыдливо умолчал.

Т.е. все фичи journald сводятся к тому, что это такой примитивный лог, который потом всё-равно приходится чем-нибудь фильтровать. В самом простом случае - грепом.

Шикарне. :D

... попросить вести дискуссию в рамках задаваемых вопросов (например)?

Бесполезно. Это же alpha, гуманитарий в худшем смысле этого слова.

Ну а может вы все-таки соберетесь с силами и прочитаете мнения авторов rsyslog и syslog-ng о том были ли у них проблемы, и о том как journald вписывается в их инфраструктуру?

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

Ну а может вы все-таки соберетесь с силами и прочитаете мнения авторов rsyslog и syslog-ng о том были ли у них проблемы, и о том как journald вписывается в их инфраструктуру?

Научись вставлять ссылки в свои комментарии вместо предложений «сходить почитать».

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

А мне уже надоело объяснять, что они «не конкурируют» фруктам типа redgremlin.

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

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

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

systemd подключает journald к stdout/stderr всего подряд (при не обходимости), так что он может собирать и отдавать вменяемым системам ведения журналов больше данных

О! Вот и Вы...

... ну, я рад. А теперь по теме. Я понимаю (брат-anonymous растолковал, да и контрольный выстрел в Ваш профиль мне продемонстрировал гифчик анимированый, что на ЛОРе доставило несусветно) почему Вы так и не можете что-нибудь ответить на мой вопрос. Теперь я постараюсь расписать более очевидно что к чему.

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

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

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

Ответить на мой вопрос Вы не захотели или не смогли потому что в данном случае возникнет второй вопрос — а нафига мне тут journald? Я полагаю что даже полный гуманитарий поймёт, что он на фиг не нужен. В особенности, если учесть что его надо будет так же докручивать (ну как минимум Storage=none ставить, чтобы он на винт сервера не гадил, ЕМНИП, это не работало путём).

Единственное, зачем нужен тут journald, так это для того, чтобы он записывал логи, потом вокруг себя собирал работающих демонов в кружок и вслух читал им логи. А то демоны позасыпают на боевом дежурстве. Ну не иначе же! :)

Есть и такая проблема, да :)

Подведены итоги, никто не выиграл, новость можно удалять:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729

Для Ъ: победителей нет, выбрать может глава TC, то бишь Bdale Garbee, и сделать это он может до 15 февраля.

Кстати, до security.debian.org добрался Iceweasel 24!

И в итоге все преимущества journalctl идут в унитаз.

Для Ъ: победителей нет, выбрать может глава TC, то бишь Bdale Garbee, и сделать это он может до 15 февраля.

Можно подумать, что мы не знаем, что он выберет.

Hertz> Неужто на макось придётся переходить :((

Там launchd, с которого по неудачным скриншотам делали systemd.

Можно подумать, что мы не знаем, что он выберет.

В свете того шума, который развёл Ian Jackson, может воздержаться.

В свете того шума, который развёл Ian Jackson, может воздержаться.

Что тогда? Всенародное голосoвание девелоперов? Или что там в правилах написано.

Hertz> На макось бежать не хочется, с но с Дебиана больше некуда.

Gentoo

Hertz> Что винда, бывшая годной во времена Windows Mobile, в эпоху КПК, когда в ходу были стилусы

Говнищем тем ещё она была. А WP и подавно говнище.