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

этого не может быть, потому что быть не может.

За бинарные логи надо бить сильно и увесисто.

Там кстати много хороших концепций. Но с аргументацией как в предыдущей реплике тебе видимо не понять.

There's «journalctl --verify»

Оно автоматически запускается при старте системы? (имеется ввиду прямая аналогия с автоматическим запуском fsck после «грязного» отмонтирования).

«append-only» model of the journal

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

Если Debian и перейдет на systemD, то наверняка и Ubuntu :)

Но, а если Debian перейдёт на upstart, то Ubuntu станет апстримом для Debian. Это будет весело, по крайней мере. Debian для Ubuntu будет как Fedora для RHEL. Свободные (относительно) художники для серьёзных дядь. И больше не будет серверов на Debian, будут на Ubuntu исключительно. Разве это плохо? :)

осталось только понять, как это «append-only» уживается с индексами для быстрого поиска по журналу.

А никак не уживается: «Objects are appended to the end as time progresses. Most data stored in these objects is not altered anymore after having been written once, with the exception of records necessary for indexing.» http://www.freedesktop.org/wiki/Software/systemd/journal-files/

То есть заявление поттеринга про «append-only» — наглая ложь.

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

Зато при старте запускается проверка флага 'offline'(метки о том, что в прошлый раз лог-файл был корректно закрыт). Если у файла такого флага нет, то он тут же ротируется, а запись начинается в новый файл с чистого листа.

как это «append-only» уживается с индексами для быстрого поиска по журналу.

Ответ Леннарта выглядит вот так:

Note that the journal files are basically just a stream of
objects. There are objects that actually carry contents, and objects
that are just useful for indexing things. When recovering a corrupted
journal file it is sufficient to recover the former (and just skip over
the rest which is the majority), the indexing can be regenerated easily.

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

http://www.mail-archive.com/devel@lists.fedoraproject.org/msg62769.html

Что ж вы нервные-то такие...

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

Так широко, я еще не задумывался об этом вопросе :)

А зря. :)
Ubuntu-server перестанет быть бесплатным, станет наконец-то прибыль приносить... Вот тогда уж Марк и заживё-от. :)

В техническом комитете уже 3 сотрудника Canonical.

Абсолютно непредвзятые и кристально честные люди, конечно же =)

Что ж вы нервные-то такие...

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

Надо просто читать целиком, а не кусками
There are objects that actually carry contents, and objects that are just useful for indexing things. When recovering a corruptedjournal file it is sufficient to recover the former (and just skip over the rest which is the majority), the indexing can be regenerated easily.

Проблема в том, что для поддержки индексирования жоурналд обновляет те секторы диска посреди файла, которые «actually carry contents» (см описания полей структуры «Data Objects» в http://www.freedesktop.org/wiki/Software/systemd/journal-files/ ). Вполне естественно ожидать, что в этих секторах при блэкауте окажется мусор. Все взрослые СУБД для записи в середину файла используют сложные схемы (например, PostrgreSQL, sqlite и MongoDB используют write-ahead-log), так что подсевшим на поделки редхатовской пионерии терпилам ещё предстоит хлебнуть говна.

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

PostrgreSQL давно славиться тем,что без ежечасного бэкапа НЕ лучше использовать

Наверное так? И с чего это такое утверждение?

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

Не нужно переводить организационные вопросы в техническую плоскость.

выбрать {что-то} и разводить холивары убеждать себя что это {что-то} лучше, а все остальное гуано.

Это как разговаривать самим с собой, но публично.

У тебя там ни организационной, ни технической плоскости нет.

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

А может проблема как раз в 1С?

ну с mssql таких проблем нет,следственно.....

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

Это истерика, а не плоскость.

чем тебе так поттеринг неугодил?

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

Новые фичи ядра не ломают стопицот стандартных механизмов и подсистем. В отличие от

Чем мы тут все и занимаемся. Да.

Ты как-то завоинствовал. Редхат даёт - беру, бьёт.. не, не убегаю! Убиваю!

Русский речь меня покинул.

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

Ну так и живите на LTE. При апгрейде обновление системы инициализации - самое невинное что может произойти

За бинарные логи надо бить сильно и увесисто.

мне вот, кстати, интересно: шапка и Леннарт лично оплатят нам допил системы анализа логов под бинарную радость? Хотя о чем я, оно ж только для локалхоста по сю пору?

Например, нам надо обновляться. И вот внезапно ...

С версии на версию? совершенно другую? без подготовки и изучения?

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

Риторический вопрос :(

Так у вас там RHEL или Debian?

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

Это истерика, а не плоскость.

Называй как хочешь, суть от этого не меняется.

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

Редхат даёт - беру, бьёт.. не, не убегаю! Убиваю!

А что, когда бьют — нужно терпеть?

Например

…можно сделать опрос на ЛОРе, по теме топика.

чем тебе так поттеринг неугодил?

Не люблю велосепидоров. А этот, к тому же, еще и лжец. «„Two-faced lying weasel“ would be the most polite thing I could say.» (c) Linus Torvalds

Экий ты.. Но это же я поговорку сказал.

Думай так: даёт лапти - беру, даёт сапоги - плюю в морду, бо к лаптям ноги присохли уже.

Детский сад, штаны на лямках.

1) systemd - штука полезная для контейнеров и виртуальных машин. То есть для облаков. Именно это и есть главная причина, по которой RH его выбирает. Несмотря на то, что до 2017 года именно они (а не вы, не Debian с Canonical, и не Gentoo с Arch) будут поддерживать одновременно три разные системы инициализации, и обеспечивать своим клиентам плавную миграцию с одной на другую.

2) логирование через journald можно отключить, направив всё напрямую в вашу любимую syslog-реализацию. Без поддержки rsyslog никто journald даже не стал бы рассматривать.

дебиан 5-6-7 обновлялся как часы, например. Впрочем, я верю, что sysvinit останется жить при любом раскладе.

«Один в поле — не воин»

И что он даст? Или чисто «дабы дурь ЛОРа видна была» всем?

Конечно, с изучением, но это как-то отменяет появление кучи проблем из-за системд?

И то, и другое. Шапки больше.

Поттерингоподелие ломает запуск серверного ПО :) Но это я тренируюсь в толщину уже :)

Ага, особенно, когда тапком не на таракана, а на папу замахивается.

вот работал с pg и всё стабильно было за 1.5 года «ни единого разрыва»

Шапка вам поможет. Деньги ж не за зря берёт.

А что? Debian и Ubuntu — родственные проекты.

Абсолютно непредвзятые

Непредвзятость непредвзятости рознь.

кристально честные люди

А это здесь (в рассматриваем вопросе) причём?