16 Bře
2021
16 Bře
'21
2:56
Hi!
I have two Debian 10 Buster systems, both patched up current, and both
running Knot 3.0.4-1~cz.nic~buster1 from the apt repository at
https://deb.knot-dns.cz/knot-latest/.
Both Knot installations have virtually identical configs .. really
only different in the related hosts and zone lists. Their logging
configs are both:
log:
- target: syslog
any: info
One of these Knot instances logs to syslog, and the other logs to
systemd-journald. I'm trying to figure out why the difference, and
I've come up empty. The Knot docs simply say that if Knot is compiled
against systemd, then a 'syslog' setting will use systemd-journald.
Mostly I want to know so that I can convince the one using journald to
stop doing that. :) What other things might trigger Knot to use
syslog on a systemd-managed host?
16 Bře
16 Bře
7:09
Matthew Pounsett wrote:
Hi!
I have two Debian 10 Buster systems, both patched up current, and both
running Knot 3.0.4-1~cz.nic~buster1 from the apt repository at
https://deb.knot-dns.cz/knot-latest/.
Both Knot installations have virtually identical configs .. really
only different in the related hosts and zone lists. Their logging
configs are both:
log:
- target: syslog
any: info
One of these Knot instances logs to syslog, and the other logs to
systemd-journald. I'm trying to figure out why the difference, and
I've come up empty. The Knot docs simply say that if Knot is compiled
against systemd, then a 'syslog' setting will use systemd-journald.
Mostly I want to know so that I can convince the one using journald to
stop doing that. :) What other things might trigger Knot to use
syslog on a systemd-managed host?
If I'm reading the knot source code correctly [0,1], knotd
unconditionally logs to the system journal interface if knotd has been
compiled with systemd support and the system is running with systemd as
PID 1. So, a better question might be why knot is using syslog at all on
one of your hosts.
On your system where you're getting knotd log output into syslog, is
knotd is actually sending the log output to a syslog daemon, or is it
sending the log output to the system journal, and systemd-journald is
forwarding it to a syslog daemon?
On Debian 10 systems, systemd-journald listens on both the system
journal sockets as well as the traditional syslog socket at /dev/log,
and systemd-journald defaults to ForwardToSyslog=yes which causes log
messages to be forwarded to a traditional syslog daemon if one is
installed. The only thing you should need to do to get log messages
dumped into the traditional text files under /var/log should be to
install a syslog daemon package like rsyslog if one isn't already
installed.
[0] log_init():
https://gitlab.nic.cz/knot/knot-dns/-/blob/v3.0.4/src/knot/common/log.c#L15…
[1] emit_log_msg():
https://gitlab.nic.cz/knot/knot-dns/-/blob/v3.0.4/src/knot/common/log.c#L21…
--
Robert Edmonds
edmonds(a)debian.org
15:13
On Tue, 16 Mar 2021 at 03:09, Robert Edmonds <edmonds(a)debian.org> wrote:
> If I'm reading the knot source code
correctly [0,1], knotd
> unconditionally logs to the system journal interface if knotd has been
> compiled with systemd support and the system is running with systemd as
> PID 1. So, a better question might be why knot is using syslog at all on
> one of your hosts.
Thanks for the links and for clarifying the source code.
That led me to find that the two systems are running different syslog
daemons. It turns out the Debian package for rsyslogd creates the
socket /run/systemd/journal/syslog, which journald writes to, and the
Debian package for syslog-ng does not.
Inconsistency explained. Thanks!
16:32
Matthew Pounsett wrote:
On Tue, 16 Mar 2021 at 03:09, Robert Edmonds
<edmonds(a)debian.org> wrote:
> If I'm reading the knot source
code correctly [0,1], knotd
> unconditionally logs to the system journal interface if knotd has been
> compiled with systemd support and the system is running with systemd as
> PID 1. So, a better question might be why knot is using syslog at all on
> one of your hosts.
Thanks for the links and for clarifying the source code.
That led me to find that the two systems are running different syslog
daemons. It turns out the Debian package for rsyslogd creates the
socket /run/systemd/journal/syslog, which journald writes to, and the
Debian package for syslog-ng does not.
Inconsistency explained. Thanks!
Hmm, even if you're using syslog-ng on a Debian 10 system it should
still be generating log messages in /var/log.
The syslog-ng package depends on syslog-ng-core, which depends on
syslog-ng-mod-journal, which "provides the systemd-journal() source
plugin, which allows syslog-ng to read directly from the systemd
Journal". Apparently syslog-ng uses the sd_journal_* API to directly
read from the journal, which explains why syslog-ng wouldn't be
listening on the syslog forwarding socket that systemd-journald attempts
to write to. So it should "just work" unless you're running a
non-default configuration.
--
Robert Edmonds
edmonds(a)debian.org
19:03
On Tue, 16 Mar 2021 at 12:32, Robert Edmonds <edmonds(a)debian.org> wrote:
The syslog-ng package depends on syslog-ng-core, which
depends on
syslog-ng-mod-journal, which "provides the systemd-journal() source
plugin, which allows syslog-ng to read directly from the systemd
Journal". Apparently syslog-ng uses the sd_journal_* API to directly
read from the journal, which explains why syslog-ng wouldn't be
listening on the syslog forwarding socket that systemd-journald attempts
to write to. So it should "just work" unless you're running a
non-default configuration.
The only non-default thing in this config is a local entry in conf.d
directing LOCAL5 to a new file.
Just to be absolutely sure the config is default, I purged syslog-ng
and then autoremove-purged its dependencies, then reinstalled. Still
nothing in /var/log/user.log from knot. I also tried removing the
default filter on user.debug just to be safe, still nothing.
I don't want to turn this into a syslog thread on the knot list,
though ... so unless you think that points to some sort of problem
with knot, we should probably take this off list (or to another list).
19:10
Matthew Pounsett wrote:
Just to be absolutely sure the config is default, I
purged syslog-ng
and then autoremove-purged its dependencies, then reinstalled. Still
nothing in /var/log/user.log from knot. I also tried removing the
default filter on user.debug just to be safe, still nothing.
Hmm, how about /var/log/daemon.log? I don't think I've ever seen knotd
log to /var/log/user.log.
--
Robert Edmonds
edmonds(a)debian.org
19:21
On Tue, 16 Mar 2021 at 15:10, Robert Edmonds <edmonds(a)debian.org> wrote:
Matthew Pounsett wrote:
Possibly due to the reinstall, I'm seeing configuration checks ('knotc
reload' output) in daemon.log now.
On the rsyslog-based system, I'm getting at least all of the DNSSEC
signing logs to /var/log/user.log. I'm not seeing that DNSSEC
activity logged anywhere on the syslog-ng system. It only shows up
via journalctl queries.
Just to be absolutely sure the config is default,
I purged syslog-ng
and then autoremove-purged its dependencies, then reinstalled. Still
nothing in /var/log/user.log from knot. I also tried removing the
default filter on user.debug just to be safe, still nothing.
Hmm, how about /var/log/daemon.log? I don't think I've ever seen knotd
log to /var/log/user.log.
1358
days inactive
1358
days old
6 comments
2 participants
participants (2)
-
Matthew Pounsett -
Robert Edmonds