Столлман и systemd

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

Никакой OpenSource тут не поможет.

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

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

Что значит унификация в твоём понимании?

Как минимум, чтобы time, cmd и depends никак не зависели от дистрибутива и страны проживания.

Mr. Richard!

Разве так принято?

Уже сказали
Ничего страшного, я думаю %)

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

золотые слова, ппкс

Никакой OpenSource тут не поможет.

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

в этом вашем journal уже можно хранить дебаг одного сервиса два дня, info другого две недели, а critical третьего - два месяца, или ротация делается по-прежнему удалением всех логов?

Ээ. Ротация делается для всего файла логов (по достижении некоторого объёма). journalctl зато прозрачно объединяет все файлы логов, поэтому тебя наверняка это не должно волновать.

Что значит прозрачно?

Не требуя никаких особых действий с твоей стороны.

Поясни подробнее. Я хочу понять удобства по сравнению с классической системой

Ну journalctl - это что-то типа cat /var/log/*.log с сортировкой по дате и изкоробочной фильтрацией по куче признаков. В смысле, не эквивалент, а аналогия.

Говорят, что это быстрее, чем «cat | grep», но я не тестил + у меня включено сжатие логов.

в этом вашем journal уже можно хранить дебаг одного сервиса два дня, info другого две недели, а critical третьего - два месяца

echo «journalctl -o export -p crit -u myservice.service --since=yesterday | xz -9 > /var/log/backup_of_very_important_log/`date +%F` » > /etc/cron.daily/save_journal.sh && chmod +x /etc/cron.daily.save_journal.sh

И храни, сколько душа пожелает.

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

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

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

Именно поэтому сначала начали системдить маргинальные дистры

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

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

Чего?

Кто-то да страдает, раз ноет

Ноют потому, что в голове каша.

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

Меня волнует, что дебага от service1 слишком много и мне не хватит никакого жесткого диска чтобы хранить его больше недели, при этом писать его надо и сохранять не-дебаг нужно дольше, чем дебаг. Пока тут привели решение как сделать это выкинув бинарные логи и утилиту journalctl.

Файлы журнала там append-only, и это вроде как фича. Значит, конкретно так он делать не умеет.

Вопрос - это случай из реальной практики или теоретизирование?

- господин президент, как продвигается ваша речь?
- я заменяю все О на А. это похоже на А?

Пока тут привели решение как сделать это выкинув бинарные логи и утилиту journalctl.

Т упрлс?

Ну journalctl - это что-то типа cat /var/log/*.log с сортировкой по дате и изкоробочной фильтрацией по куче признаков. В смысле, не эквивалент, а аналогия.

Эм. Т.е. вместо того, чтобы сделать

 $less /var/log/openser.date.log

 $journalctl <option-list> 

Файлы журнала там append-only, и это вроде как фича

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

Значит, конкретно так он делать не умеет.

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

Вопрос - это случай из реальной практики или теоретизирование?

конечно из реальной практики, ты никогда не менял количество сохраняемых файлов logrotate что-ли?

разве не ты мне сказал, что сделать это можно написав такой нелюбимый всеми systemd-шниками shell-скрипт и сохранив лог как ужасный plain-text?

кстати

1. я хочу чтобы это был не шелл-скрипт, запускаемый из cron, а systemd-шный unit файл, ведь у нас даже cron-а нет, т.к. systemd заменяет cron.

2.с --since=yesterday не будет дублирования записей или наоборот возможности потери записей если наш скрипт будет выполнятся не секунда в секунду в одно время?

Я тебе не сильно мешаю? А то я погляжу, что ты уже мне точку зрения приписал, успешно с ней поспорил, я, как бы, и не очень нужен. 1) -o export — это не плейн-текст (в котором, к слову ничего плохого нет), а штатный формат для бэкапов и передачи по сети (а тебе нужен именно бэкап), 2) шелл-скрипты для того и нужны, чтобы малой кровью создавать нестандартные конфигурации.

я хочу чтобы это был не шелл-скрипт, запускаемый из cron, а systemd-шный unit файл

Да без проблем, оно делается на раз.

у нас даже cron-а нет, т.к. systemd заменяет cron.

Тебя чудо-трава никак не отпустит? Он не заменяет cron.

с --since=yesterday не будет дублирования записей

Будет, но тебе никто не мешает сделать и бесшовный лог, только чуть сложнее будет выглядеть.

Рекомедную встраивать код в таблицы для расчёта crc32.

-o export — это не плейн-текст, а штатный формат для бэкапов и передачи по сети

ок, но ты потом ещё через xz прогоняешь, journalctl умеет сам его разархивировать или теперь мне для поиска нужно будет сначала все распаковать?

(в котором, к слову ничего плохого нет)

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

(а тебе нужен именно бэкап)

нет, мне не нужен бекап, мне нужна настраиваемая ротация логов, если для тебя это одно и то-же - можешь думать что это одно и то же.

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

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

Будет, но тебе никто не мешает сделать и бесшовный лог, только чуть сложнее будет выглядеть.

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

Да без проблем, оно делается на раз.

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

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

Если этого ещё нет, значит, это никому ещё не было нужно. Наличие существующих пользователей systemd, среди которых есть как минимум один энтерпрайз в лице компании Spotify с 5K машин на systemd, объективно показывает, что конфигурация такая нужна действительно не всем.

Так вот. Если бы это была винда, то ты бы на данном моменте лососнул тунца. Но поскольку это FOSS, то ты идёшь в systemd-devel@freedesktop.org и постишь туда RFE. Или, в идеале, открываешь свою любимую IDE и пишешь этот функционал самостоятельно, после чего идёшь всё туда же и постишь RFC.

А ныть на ЛОРе достаточно бессмысленно, и тов. alpha наверняка это подтвердит.

Если этого ещё нет, значит, это никому ещё не было нужно.

нет, не значит.

Наличие существующих пользователей systemd, среди которых есть как минимум один энтерпрайз в лице компании Spotify с 5K машин на systemd, объективно показывает, что конфигурация такая нужна действительно не всем.

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

Так вот. Если бы это была винда, то ты бы на данном моменте лососнул тунца. Но поскольку это FOSS, то ты идёшь в systemd-devel@freedesktop.org и постишь туда RFE. Или, в идеале, открываешь свою любимую IDE и пишешь этот функционал самостоятельно, после чего идёшь всё туда же и постишь RFC.

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

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

Ну и для примера, RFE насчет time-based ротации:

https://bugzilla.redhat.com/show_bug.cgi?id=864629

ну как, ответил дядюшка Ричи? :)

Я на самом деле ждал его ответа на вопрос можно ли это опубликовать, но думаю, что можно и пережить.

Richard Stallman
12:13 AM (19 hours ago)
to me
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
I know too little about systemd to have a technical opinion about its
design. However, I know one very bad practical disadvantage:
it works only with Linux, not with other kernels.

cast NeverLoved

Ух!

В голос!
Спасибо:)

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

Это же просто говнокод. Кто им будет пользоваться? Откуда «вендорлок» возьмется?

Да, `systemd --user` пишет в свой лог, но пользоваться этим для разделения логов - это же первый приз по спортивному извращению :)

нет, не значит.

Если не учитывать буквоедское «нужно и сейчас пишется», то не верю. Контрпример было бы неплохо.

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

Я этого не утверждал. Если им не хватает функционала journald и они решили использовать другой софт - то они поступили совершенно валидно.

ещё чего, у меня и так есть готовые решения, которые это умеют

Аргументный аргумент. Тогда хотя бы не ной на ЛОРе.

Linux в опасности, или новый Эллоп (комментарий)

Что-то там тема «вендорлока» не раскрыта. Пользователь всегда зависит от разработчиков, не важно open source это или нет. Только в случае open source у пользователя всегда есть возможность самому стать разработчиком (прямо или косвенно) и развивать проект в нужную ему сторону.

Кот бы говорил. Попробуй заслать патч, делающий logind опциональным.

Мне-то зачем засылать патчи? А вот если вдруг IBM решит, что на их серверах какие-то компоненты вроде systemd и т.п. работают не так как нужно, то или «зашлют патч», или переделают так как им будет нужно и никакие «вендоры» вроде RedHat им не помешают.

а ты попробуй заслать все-таки, не виляй

Т.е. «вендорлок» определяется возможностью «заслать» в проект какую-то «хрень», которую разработчики не хотят там видеть?

Не хрень, а свой патч, то есть выразить свою точку зрения на функционал продукта.

выразить свою точку зрения на функционал продукта

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

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

все верно написал

ППКС.

К слову, аналогичная аргументация пригодна против «всё привязывают к systemd, ко-ко-ко». Всё просто - systemd предоставляет API, которые 1) полезны разработчикам и 2) никто больше не предоставляет.