syslog-ng можно использованить вместе с вместе c systemd-journald для приема логов от последнего и в этом случае зависимость от syslog-common является избыточной. Нельзя ли ее оторвать? Да, юнит для запуска тоже бы не помешал.
Мне кажется, что писать локальные логи - это основное занятие 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
