> Потому, что прибитый к systemd он автоматом прибивается к линуксу

Не используйте systemd - и наступит счастье!

Только вот, походу, у дистростроителей нынче оно в моде.

Мало, видать, всем было траходрома с первым (avahi) и вторым (pulseaudio) поделиями поттеринга... Нет, еще один зонд себе засунули.

Пусть попаболь, зато как у всех! ;-)

мда. посмотрел на зависимости Build-Depends в Debian: там и libdbus-1-dev, и libgtk2.0-dev - и еще простыня на штук 20 строк...

> посмотрел на зависимости Build-Depends в Debian: там и libdbus-1-dev, и libgtk2.0-dev

Из сырцового пакета строится и морда. Внезапно, да?

+очень много

ст. 282. ненависть к социальной группе бинарологофилов

кто сказал, что у меня есть ненависть ? У меня есть цель

и будет еще толще.. Т.к. не KISS.

И этот клоун хвалится, что именно его система минималистична:
-->8--

Systemd is bloated. It apparently attempts to take over the roles of

init, cron, at, inet, ConsoleKit, sethostname, modprobe, mount -a, and

probably others. The result is that you end up running 50000 lines of

C code as PID 1, as compared to the 8000 lines of SV init or the 6000

lines of runit.

Seriously?

You have a pretty bogus definition of bloat.

If you want to compare systemd in lines-of-code with sysvinit, then you
need to sum everything up: inetd, the numerous rcS scripts and
even the enourmous duplication that sysv init scripts are. And yes,
systemd will easily win if you do: it will be much shorter.
-->8--

Человек в упор не видит, что 100% этого «кода на shell», системные утилиты (mount, etc) и т.д. - все это работает не только при инициализации, все эти тонны _отлаженного_ С-кода. А сугубо ради инициализации - работают только строчки на достаточно высокоуровневом языке. Самая оптимистичная оценка у меня получилась в 10k такого... С шахматами и поэтессамикомментариями и пустыми строками.

Ну, dbus-таки остается потом и в зависимостях systemd. И много еще что из списка...

Репост комментария Solar Designer на opennet:
-----------------------------------------------

Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов.

Это было реализовано в ssyslogd от CORE-SDI в конце 90-х, позже дополненным работой с базами данных и названным msyslog:

http://oss.coresecurity.com/projects/msyslog.html

Оказалось слабо востребовано.

Данные сообщений не аутентифицированы. Например, любой локальный процесс может указать что он Apache с PID 4321, а syslog поверит этому и сохранит сведения в лог

Да. Исправлено в Owl небольшим патчем к sysklogd:

http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/sysklogd/

(см. sysklogd-1.4.2-owl-syslogd-unixcred.diff).

Передача по TCP и другие улучшения по одному и в разных сочетаниях также реализованы в разных альтернативных syslogd'ах.

В целом, идея переписать syslogd - здравая - хотя сделать это хорошо не просто, да и что такое хорошо - спорно. Вероятно, если это будет сделано в Fedora, оно приживется, несмотря на то что отдельно это была бы лишь еще одна слабо востребованная альтернатива со своими недостатками.
------------------------------------------

>> базовые величины можно проиндексировать заранее

Время на индексацию сам посчитаешь? А не постоянную переиндексацию, поскольку данные постоянно валятся?

машинное время дешевле (значительно!) человеческого, потому в 90% случаев пофигу на доп затраты на индексацию при записи, если это помогает в анализе логов.

> PUSH/PULL это «еще одна реализация scp». Она не дает онлайновости.

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

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

Так толсто, что даже тонко.

> Так что лучше бы поттеринг заткнулся, сделал нормальный API для нового логгера, написал бы расширяемый логгер с плагинной архитектурой и, если уж ему так вперлось сделать бинарный лог, сделал бы его. Через plugin. А более разумные люди сделали бы другие плагины. И самое главное - не прибивать ЭТО гвоздями к systemd. Потому, что прибитый к systemd он автоматом прибивается к линуксу, а это плохо.

тут согласен. с учетом, что systemd может работать в journald сразу со старта ядра. плагинистость это позитивно, хотя основной плагин хранения ИМХО это БД-подобное.

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

> Изредка? Ну-ну. Есть тут у меня база всего лишь с 30 миллионами записей в одной табличке и конкурентной вставкой в неё - так вот это та ещё задница. А механизм транзакционности обновления индексов поттеринг тоже сумеет реализовать, да с согласованым чтением, да при конкурентном доступе?

30 миллионов это было много лет 8 назад. сейчас довольно средненький объем. тут только конкурентные транзакции могут подпортить крови.

> Исправлено в Owl небольшим патчем к sysklogd

И в rsyslog с 5.7.1. Там, кстати стоит: «thanks to Lennart Poettering for the suggesting this feature». Не все потеряно - чукча и читать умеет? ;)

В целом, идея переписать syslogd - здравая

Идея «переписать нах» - попусту безумна. Здравой она становится после перечисления конкретных недостатков существующей системы и ее альтернатив (тот же rsyslog).

>Если мы хотим 99%й популярности ОС

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

>медленного интернета больше нет, а простые пользователи не пользуются ssh и консолью (разве что в случае ЧП)

ущипни себя и проснись, нео

>Как? Каким образом?

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

А чем это лучше чем то, что есть сейчас?

Вот чем хуже я вижу. Компактность логов мне ни в ...ду, а читать я могу текстовые чем угодно.

>базовые величины можно проиндексировать заранее, так что большинство common запросов будет работать быстрее by design

А чего тогда всякие nepomuk-серверы тормозят?

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

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

>и с кодами ошибок которые нужно ещё унифицировать и где-то как-то иметь возможность просмотреть/расшифровать,

Т.е. перекорячивать каждую прогу.

При этом еще писать null в неподходящие поля или плодить туеву хучу таблиц и все это дерьмо хранить в одном месте.

И упаси господь стереть руками старые данные...

велосипедисты

> нужно добавить передачу по сети и работу коллектором
велосипедисты такие велосипедисты

писать null

> писать null
тонко :)

>срочно допиливать GNU/Hurd и сваливать на него

может инферно овер ядра линукс проще будет допилить ?

как то не вериться в допиливаемость GNU/Hurd

>мне и интересно было, почему вы решили, что всё будет так прозрачно.

Потому что прозрачно, это когда программа-клиент как посылала, так и шлет сообщение стандартным вызовом syslog() и от этого ничего не ломается.

Вот вам цитата:

--------

(в fedora 17) пользователь практически не заметит journald, за исключением того, что “systemctl status” будет показывать последний вывод логов для всех служб.

----------

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

И далее

-----------

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

----------------

Вот как пользователь будет «играть с новыми клиентскими утилитами» журнала, если не будет бинарных индексов журнала?

у вас тоже в переводе нет ни слова о том, что «сообщение появится как в обычном файле сислога, так и в дополненом защищеными полями и бинарными индексами виде в журнале»:

Я не знаю, что еще можно добавить к этой цитате изи статьи:

-------------------- Вы можете запускать rsyslog или syslog-ng бок о бок с журналом и сообщения сислога будут сохраняться и в rsyslog/syslog-ng и в журнале. Тем не менее, журнал будет хранить множество мета-данных вместе с сообщениями сислога, а обычный syslog нет. ------------------------------

Более того, Леннарт ясно написал, что вызов syslog() и дальше останется основным. А вызов родной для журнала функции добавления записи останется только для тех случаев, когда необходимо записать в журнал бинарные данные или дополнительные поля, например, тип сообщения. Или отдельное поле, например, с айпишником логинящегося пользователя., чтобы не парсить его из текста.

Вот этот кусок:

-------- Нет, прежде всего, syslog API syslog(3) поддерживается как интерфейс первого класса для записи сообщений в лог, и продолжает оставаться главным API для всех простых текстовых логов. Тем не менее, как только потребуется присовокупить к тексту метаданные (возможно, двоичные метаданные), потребуется использовать вместо него нативный journal API.

-------

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

перенаправление будет, но откуда и куда - непонятно.

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

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

2) следить за непостоянным списком логфайлов само по себе нереально. И заодно пропадет возможность дополнять записи в журнале неизменяемыми полями типа пид процесса, уид и т.п.

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

вы растеклись мыслью по древу.
имеем сбоку бантик в виде нового журнала, работающего параллельно с syslog'ом. замечательно. бантик проектируется изначально хреново, в виде велосипеда с квадратными колёсами. весь тред об этом.
формат лога надо стандартизировать - да (имхо). можно было бы сохранить текстовый вид хранилища, но добавить индексы и инструменты просмотра? да. можно было и бинарный вид принять, но не изобретая велосипед (есть масса форматов БД на простых файлах, включая встраиваемые хранилища). не надо приумножать сущностей без крайней на то необходимости.

Тебе - не обязательны :)

Блеать, я думал хуже Гнума 3 ничего не может быть. Оказывается, может.

> О жёстком прессинге говорит r и другие серьёзные люди, которые работают с гигабайтными логами и приложениями, не допускающими остановки.

Да, кстати, хочу дополнить. В enterprise отлично работает сислог и перекручивает сотни гигов данных. На десктопах дай дог 50 метров доберется. И хомячки эти логи не читают. Почти все доводы поттера мимо кассы, потому что он замахивается одновременно на две нишы - enterprise и home media desktop, ничего не понимая в первом. Если тщательно вдуматься, то ему нужно от сислога логгирование ранних сообщений и запись туда блобов. Блобы в базе - это адова жесть. Их нужно хранить на диске. Ранние сообщения выводятся в терминал, а systemd, как ты уже говорил, может писать во временный лог или вообще в память складывать.

Проблема в том, что не совсем ясен юз-кейс этих самых ранних логов. Да, это круто, НО. Если у тебя десктопная машина - ты смотришь в нее глазами. Если не грузится один из тысяч серверов - ты ВСЕ РАВНО пойдешь к нему либо физически, либо через IP-KVM и будешь смотреть опять таки в монитор.

Потому что Oracle понимает, что логи пишутся по большей части для людей и для анализа сбоев. Это, действительно, черный ящик. Вероятность падения базы до состояния полной некондиции больше, чем текстового файла. Я сталкивался с ситуацией, когда просто выпадал кусок текста из-за того, что посыпался диск. И все равно большая часть информации легко читалась и парсилась.

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

Во время работы над пульсой у него вылезали фатальные недостатки в виде кривости плееров, альс, ядер и прочего. Зато пульса вся такая золотая и непогрешимая. Далее, systemd. После того, как его внедрили в федору (мое терпение в этот момент лопнуло и я свалил на арч), зоркий глаз заметил, что ему нужен /run и /usr со всеми бинарниками на корне.

То есть, леннарт абсолютно не способен хоть как-то предсказать развитие своего софта. Судя по коду, он посредственный кодер, а проектировщик вообще никакой. Почему его RH не погнали ссаными тряпками - я искренне не понимаю.

> И вообще, судя по тексту сообщения, человек совершенно не представляет, как нужно проектировать такие системы.

И фраза «мы оставляем за собой право менять формат лога» только подтверждает мои слова. Что такое compatibility, чел тоже не знает.

> ты ничего не понимаешь в работе лидера

Это называется не «лидер», а «системный архитектор». И из леннарта он - как из слона балерина. В любом случае, тимлид должен организовывать, руководить и кодить. Ничего этого он нормально не умеет.

ты поймешь

Я и так понимаю. Смотрю, какой лог по дате мне нужен и грепаю его. No problems.

Каждую секунду что-то не работает и пишет в лог «аааа спасити памагити нет пути».

4.2. В нормально настроенной системе и в продакшне это нонсенс.

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

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

Сисадмину это вещь #1. А простому пользователю такую штуку неплохо было бы повесить в качестве виджета на рабочий стол, например.

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

придется потратить много больше 9000 человекочасов,

4.2, недавно писал на коленке за полчаса.

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

>При этом использование компактных бинарных логов вообще избавляет во многом от активного logrotate'а, что явно облегчает задачу автоматизации анализа логов в тех же BASH-скриптах.

Бинарные логи (!) с переменным форматом (!!) облегчают автоматизацию анализа(!!!)? Да ты с дуба рухнул. Мало того, что ты не сможешь без специальной утилитки, заточненной под конкретную версию лога, прочитать их, так еще и при малейшем нарушении целостности такого лога его вообще прочитать невозможно будет.

>С другой стороны, работает же systemd - вроде никаких особых нареканий к нему нет.

Ага... до тех пор, пока всё в / зафигарено. А как только появляются разделы с вида / на sda1 /usr на sda2 и т.д. так сразу systemd начинает лажать помаленьку. И гениальное решение этой проблемы предлагается - давайте все в одну папку скидаем, иначе наша поделка кривовато работает. Потом оказалось, что с syslog'ом она тоже не очень работает и какой выход предлагается? Правильно, сделать костыль, совместимый с systemd, но не совместимый с syslog. А через год-другой окажется, что ядро не очень совместимо с systemd...

>И да, вполне возможно, что софт для вывода бинарного лога на stdout или куда там, будет считывать сообщения из /usr/share/logger

Ага... система не взлетела - скажем /usr накрылся частично и как теперь ты собирается узнать что причиной этому было «событие 0xc00dae»? Или еще веселее - лог побился...

> После того, как его внедрили в федору (мое терпение в этот момент лопнуло и я свалил на арч), зоркий глаз заметил, что ему нужен /run и /usr со всеми бинарниками на корне.

Ну просто тред-детектор нечитателей и неходителей по ссылкам.

Еще один. Да сегодня урожай на нечитателей.

>По-моему, проблема как раз в этом, а не в том, что бинарный формат чем-то объективно плох.

Бинарный формат объективно плох. Ибо расчитан он только на штатное поведение системы и совершенно не преспособлен под разносные ситуации, при которых как раз логи и нужны позарез.

> Ну просто тред-детектор нечитателей и неходителей по ссылкам.

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

Для Ъ:

В Федоре куча софта уже давно упакована так, что программы, которые должны запускаться до монтирования /usr, зависят от файлов в этом самом /usr. И только когда Поттеринг стал впиливать туда свой systemd и тестировать работу этого барахла, до индейцев дошло, что у сарая не было стены.

После этого родилась гениальная идея «раз оно давно поломано, напишем, что это фича».

А в нештатных ситуациях syslog работает всегда? Даже если libc.so подменить на что-то совсем левое?

>А в нештатных ситуациях syslog работает всегда? Даже если libc.so подменить на что-то совсем левое?

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

>Еще один. Да сегодня урожай на нечитателей.

Это про генетические проблемы федоры-то?

Угу

> Угу

Вместо того, чтобы исправлять проблему, они объявили ее фичей. Это так по-поттеровски.

Кто-то вызывает mount -a кроме как при старте системы? Кому-то нужны эти shell скрипты кроме как для старта сервисов?

linux-way - сотня разных сислогов, так что уже и названий не осталось (syslog-ng), а работает один, и тот плохо

> Эм. А разве он сам не инит?

вот именно что такой вопрос возникает

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

>> Вот не вижу я никакой разницы в легкости отладки между пульсом и systemd

А она есть.

... но только при условии, что автор специально не лезет в дебри

а он лезет — случаи, когда обычные проги через альсу работают, а пульс — нет, означает именно то, что автор полез в дебри (например, поставил слишком сложную задачу, когда можно и нужно ограничиться решением простой)

> системд еще хочет себя юзать в качестве менеджера сессий на десктопе

facepalm.txt