а зачем?

Тебе форвард чем-то конкретным мешает или просто по религиозным причинам?

Вроде 100500 раз уже обсуждалось. Никак.

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

Вроде ж никак.
By design — from systemd with love.

Чем-то конкретным: сервис, который просто читает и пересылает логи с одного сокета на второй — не нужен. Тебе так не кажется? Он жрет процессорное время, занимает лишние ресурсы и служит ещё одной точкой отказа (замечу, что объем пересылаемых логов исчисляется от сотен мегабайт до нескольких гигабайт в час).

Это называется адаптер. Этот сервис может уметь слать логи в разные места, и его проще переделать, чем вносить те же изменения в сам systemd. В системе и даже в ядре адаптеров очень много, включая драйверы, udev и прочие вещи. Да даже банальный компилятор, который умеет собирать код под разные архитектуры, а не только под твою конкретную. И это нормально. Если ты видишь конкретные тормоза в системе и уверен, что они вызваны именно journald — добро пожаловать на багтрекер systemd.

поставить openrc?

Опять бояны полезли: церковь святого сислога, вечерняя молитва админов локалхоста :-D

Раз вы такие труЪ-энтерпрайз с пупер-нагруженными сервисами, могли бы уже и заказать допиливание systemd под себя. Или это опять батхёрт админа библиотеки имени Задрищенко?

Никак.

Myth: systemd is not modular.

Not true at all. At compile time you have a number of configure switches to select what you want to build, and what not. And we document how you can select in even more detail what you need, going beyond our configure switches.

This modularity is not totally unlike the one of the Linux kernel, where you can select many features individually at compile time. If the kernel is modular enough for you then systemd should be pretty close, too.

Это тестирование пригодности systemd к продакшену и продвинутому домашнему использованию.

sudo cast Darth_Revan. Я знаю, что он умеет.

Совсем выкинуть journald я не умею.

И даже бага/фичреквеста в багтрекере нету? Вроде писали, что у них есть это в TODO. Только я не могу найти это самое TODO и этот пункт.

Он сейчас и стоит.

А что делать, если journald не умеет работать с сислогом по сети, хотя syslog — это стандарт, и его умеют как другие ОС, так и железки.

А что делает journald такого, без чего systemd не может работать?

Преобразовывать внутренние структурированные логи systemd в формат syslog можно и обычной библиотекой, и отсылать их через syslog(int priority, const char *format, ...), для этого не обязательно держать постоянно запущенным демон, и уж тем более не надо читать все логи из /dev/log.

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

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

Вот это хз, не пробовал его останавливать.

Неужели не очевидно? Перенаправить его в syslog, который и отправит сообщения дальше по сети. Либо использовать встроенную поддержку http, который тоже стандарт и который, что характерно, поддерживает куда большее количество ОС и железа.

Неужели не очевидно? Перенаправить его в syslog, который и отправит сообщения дальше по сети.

Вопрос — зачем тогда journald в этом случае?

Либо использовать встроенную поддержку http, который тоже стандарт и который, что характерно, поддерживает куда большее количество ОС и железа.

LOLWUT. Покажи мне поддержку пересылки логов по http в формате journald (в чём они там... в JSON?) в Cisco, FreeBSD, Juniper, RouterOS и в других железяках и ОС.

К тому же, для нормального журналирования journald должен ОТПРАВЛЯТЬ записи в момент их появления, а не ждать, пока кто-то соединится, чтобы их прочесть.

И даже бага/фичреквеста в багтрекере нету?

Читал где-то в рассылке, что Леннарт считает само отключение деструктивной фичей, как-то так.

Он жрет процессорное время, занимает лишние ресурсы

сколько у тебя он потребляет?

от 10-15% до 40-50% в пике, одно ядро на 2.4 Ghz (тестовый стенд).

Думаю, что от туевой хучи локальных логов. Там поднято несколько инстансов приложений, которые слушают TCP и UDP-порты для одной хрени, туда прилетает много данных, которые преобразовываются в syslog-сообщения, должны анализироваться локальным syslog-сервером и раскидываться на удаленные syslog-сервера. На openrc с простым rsyslog проблем нет, он вполне справляется с простым перемалыванием данных, дропанием лишнего и пересылкой куда надо.

Блин, это ж обычный форвардинг с сокета на сокет. Почему оно так много жрёт?

Читал где-то в рассылке, что Леннарт считает само отключение деструктивной фичей, как-то так.

Сказочный девелопер...

Он у тебя точно ничего не складирует сам? Покажи journald.conf

это ж обычный форвардинг с сокета на сокет. Почему оно так много жрёт?

хз. Видимо, пора тебе писать багрепорт. Ибо если это является TODO systemd, фича отключения journald появится весьма нескоро.

Никак. Он цепляется к stdin/stderr к дополнительно, и systemd на него расчитывает. Можешь написать плагин к rsyslog, который будет делать тоже самое :]

Почему оно так много жрёт?

perf top

пора тебе писать багрепорт

Багрепорт, што эта? Не провоцируй. Хватит нам нытья на лоре.