Мне кажется, что писать локальные логи - это основное занятие syslog, так что отрывание зависимости на syslog-common не является оправданным. Если же речь о том, чтобы сделать из syslog-ng подпорку для journald для пересылки логов на syslog-сервер, то это задача самого journald, надо трясти там. Нашлось такое вот обсуждение: http://systemd-devel.freedesktop.narkive.com/qzNJp36N/journald-syslog-forwarding . Но вот чем кончилось в итоге, не очень понятно.

(В ответ на комментарий №1)

> Мне кажется, что писать локальные логи - это основное занятие syslog

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

> ... сделать из syslog-ng подпорку для journald для пересылки логов на
> syslog-сервер, то это задача самого journald, надо трясти там

Соглашусь, завел багу https://github.com/systemd/systemd/issues/2642, может и отреагируют.

unit-файл, который стоило бы положить в следующую сборку, может выглядеть так:

# cat /etc/systemd/system/syslog-ng.service
[Unit]
Description=System Logger Daemon
Documentation=man:syslog-ng(8)

[Service]
Type=simple
ExecStart=/sbin/syslog-ng -F $SYSLOG_NG_OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
EnvironmentFile=-/etc/sysconfig/syslog-ng
StandardOutput=journal
StandardError=journal
Restart=on-failure

[Install]
WantedBy=multi-user.target

Я использовал Type=simple, чтобы проще было в случае крайней необходимости (-e в /etc/sysconfig/syslog-ng) вывести логи самого syslog-ng в journald. Иначе хватило бы:

[Unit]
Description=System Logger Daemon
Documentation=man:syslog-ng(8)

[Service]
Type=forking
ExecStart=/sbin/syslog-ng $SYSLOG_NG_OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
EnvironmentFile=-/etc/sysconfig/syslog-ng
Restart=on-failure

[Install]
WantedBy=multi-user.target

Еще было бы неплохо Type=notify, но тут и правда может потребоваться линковка с каким-нибудь libsystemd*, и если этого хочется избежать, то можно и не делать. Однако систем с udev и без libsystemd* уже видимо не бывает.

(In reply to comment #3)

> Однако систем с udev и без libsystemd* уже видимо не бывает.

Пока в системе без systemd сидят только libsystemd и systemd-utils.

(In reply to comment #2)

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

Если syslog нужен исключительно для перенаправления на другой сервер логов от journald, то, может, просто собрать именно такой подпакет, со своим частным конфигом, без зависимости на пакет syslog-commons, и обозвать его как-то вроде %name-redirector ? И ещё посмотреть, на базе чего лучше, может быть, rsyslog меньше по размерам будет и по зависимостям, и его будет достаточно.

> Если syslog нужен исключительно для перенаправления на другой сервер логов от
> journald, то, может, просто собрать именно такой подпакет, со своим частным
> конфигом, без зависимости на пакет syslog-commons, и обозвать его как-то вроде
> %name-redirector ? И ещё посмотреть, на базе чего лучше, может быть, rsyslog
> меньше по размерам будет и по зависимостям, и его будет достаточно.

А какой демон будет в %name-redirector? Тот же, что и в %name? Тогда надо выделять некий %name-base (без зависимости на syslog-commons и поэтому с минимальным конфигом вроде простого складирования всего поступающего в один файл), которого будут хотеть %name и %name-redirector. И, кстати, мне тогда %name-redirector и не нужен будет :)

rsyslog для этих целей будет менее удобен, т.к. с документацией и синтаксисом конфигурационного файла у него хуже.

(In reply to comment #6)

> А какой демон будет в %name-redirector? Тот же, что и в %name?

Да.

> Тогда надо выделять некий %name-base

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

(В ответ на комментарий №7)
> (In reply to comment #6)
> 
> > А какой демон будет в %name-redirector? Тот же, что и в %name?
> 
> Да.
> 
> > Тогда надо выделять некий %name-base
> 
> С одной стороны да, с другой не хочется плодить пакеты свыше необходимого ради
> временного (надеюсь) решения. Вроде бы, rpm допускает упаковку одного файла в
> два подпакета сразу.

Пожалуй, один бинарник в два пакета - это приемлемо, главное чтоб при вытягивании плагинов не вытянулся в итоге syslog-commons :)

Собственно редирект из journald в remote syslog - это не основная задача, для ее решения (если апстрим не сделает), можно маленького демона написать, вот даже кто-то озаботился - https://github.com/pmorton/journalfwd,

Основная - коллектор с фильтрами и с хранилищем не в файловой системе, а в БД (тут уже изобретением велосипеда заниматься не хочется). Т.е. я не рассматриваю это решение как временное.

Вроде бы в восьмой ветке rsyslog-а одумались и сделали человеческий синтаксис (rainerscript), старый ужас оставили только для совместимости. Официальная документация (http://www.rsyslog.com/doc/v8-stable/) тоже выглядит неплохо.

(В ответ на комментарий №9)
> Вроде бы в восьмой ветке rsyslog-а одумались и сделали человеческий синтаксис
> (rainerscript), старый ужас оставили только для совместимости. Официальная
> документация (http://www.rsyslog.com/doc/v8-stable/) тоже выглядит неплохо.

Да, спасибо, там и парсер, похоже, лучше ловит блох, смотрю еще раз

Господа, с вашего позволения я закрою эту багу.
В сизиф отправлен syslog-ng-3.12.1, в котором я добавил unit для systemd. Кроме сбора локальных логов, для syslog сервера очень частая задача - приём логов по сети от других устройств(серверов) - syslog коллектор.
unit для systemd позволяет корректно запустить syslog-ng в окружении systemd, как раз в первую очередь для этих целей. Если нужно собирать логи с локального сервера, то проще включить ForwardToSyslog=yes в /etc/systemd/journald.conf

(In reply to comment #11)

> Господа, с вашего позволения я закрою эту багу.
> В сизиф отправлен syslog-ng-3.12.1,

Баг в теме, по сути, двойной. По первой части никаких возражений, в системе с sysv unit-файл не мешает. :-)

Что касается второй части, про syslog-common dependency, то это надо бы пометить, как NOTABUG.

Кстати, а плагин для работы с systemd нет желания собрать попробовать ? Я так понимаю, тогда syslog-ng сможет логи забираьт вне зависимости от настроек systemd.

(В ответ на комментарий №12)
> (In reply to comment #11)
> Что касается второй части, про syslog-common dependency, то это надо бы
> пометить, как NOTABUG.

я в rsyslog поступил следующим образом - функционал для локальной работы выделил в отдельный подпакет rsyslog-classic, в котором есть зависимость на syslog-common, drop-in настройка для systemd, и генератор конфига для использования сокетов из /etc/syslog.d/*
Без rsyslog-classic, rsyslog можно использовать как коллектор логов.
Возможно также можно сделать для syslog-ng.

> Кстати, а плагин для работы с systemd нет желания собрать попробовать ? Я так
> понимаю, тогда syslog-ng сможет логи забираьт вне зависимости от настроек
> systemd.

libsdjournal.so и так собирается и присутствует в предыдущих версиях. Или что-то другое имеется ввиду?

(In reply to comment #13)

> libsdjournal.so и так собирается и присутствует в предыдущих версиях. Или
> что-то другое имеется ввиду?

Хм. И правда, относительно моей последней сборки появился BuildRequires: libsystemd-devel. Но надо было тогда и в отдельный подпакет вынести, как остальные плагины.

(В ответ на комментарий №14)
> (In reply to comment #13)
> 
> > libsdjournal.so и так собирается и присутствует в предыдущих версиях. Или
> > что-то другое имеется ввиду?
> 
> Хм. И правда, относительно моей последней сборки появился BuildRequires:
> libsystemd-devel. Но надо было тогда и в отдельный подпакет вынести, как
> остальные плагины.

libsdjournal.so собирался и раньше, просто заголовки из systemd свои носил.
Сам выненешь в отдельный пакет или мне?

Ок, я начал, я и выделю в подпакет.
Отправил на сборку новую версию 3.13.1-alt1.

(In reply to comment #16)

> Ок, я начал, я и выделю в подпакет.

Спасибо. Что-то у меня весь день бегодня сегодня, а вчера вечером поленился в багзилле ответить.

(В ответ на комментарий №13)
> (В ответ на комментарий №12)
> > (In reply to comment #11)
> > Что касается второй части, про syslog-common dependency, то это надо бы
> > пометить, как NOTABUG.
> 
> я в rsyslog поступил следующим образом - функционал для локальной работы
> выделил в отдельный подпакет rsyslog-classic, в котором есть зависимость на
> syslog-common, drop-in настройка для systemd, и генератор конфига для
> использования сокетов из /etc/syslog.d/*
> Без rsyslog-classic, rsyslog можно использовать как коллектор логов.
> Возможно также можно сделать для syslog-ng.

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

(In reply to comment #11)

> Господа, с вашего позволения я закрою эту багу.
> В сизиф отправлен syslog-ng-3.12.1, в котором я добавил unit для systemd.

А оно точно получилось рабочее? Я тут попробовал посмотреть syslog-ng 3.20.1-alt4 из задания 224120 (бакпорт в p8), и что-то я не вижу, что syslog работает. Завёл отдельный Bug 36454