On Fri, 08 Aug 2025 at 21:16:05 +0200, Antoine Le Gonidec wrote:
documenting logging daemons
...
That systemd-journald is excluded should probably made explicit, I guess
I understand why some would expect to see it handled by our team.
I think a source of confusion is that systemd-journald is:
- a sink that receives and stores kernel log messages
- a sink that receives and stores user-space system log messages
- the[1] listener on /dev/log that receives the messages passed to
POSIX syslog(3)
and is often (by default, since bullseye), but not always:
- a sink that receives and stores system log messages *persistently* on
disk (/var/log), as opposed to merely having a transient ring-buffer
(/run/log)
but it is not:
- an implementation of the RFC 3164 or RFC 5254 syslog protocols[2]
- a sink for system messages written one-per-line to a series of flat
text files in the traditional Unix way
All of those are properties that we might reasonably think might be the
definition of what it is to be a logging daemon. So depending on your
definition of a logging daemon, it's possible that either systemd-journald
obviously is one, or it obviously isn't one, or it's non-obvious.
There are plenty of other pieces of software in Debian that match some
of these criteria but do not match other criteria, like the logging
infrastructure in runit, daemontools and similar packages, which write
messages to flat text files and are responsible for recording the output
of system services, but are unrelated to /dev/log. Are those logging
daemons or not?
Conversely, if rsyslogd has been configured to receive input from
systemd-journald and write output into a SQL database, does that mean it
has somehow ceased to be a logging daemon? After all, in that scenario,
it isn't (directly) listening on /dev/log, it isn't implementing RFC
5254, and it isn't writing out any flat text files... but it does
receive system log messages and store them.
- Logging daemons are supposed to Provides/Conflicts system-log-daemon
Whether that's true rather depends on what you understand a "logging
daemon" to mean.
smcv
[1] if you are using our default service manager, it is the only thing
that is able to listen on /dev/log; other /dev/log receivers are
available if you are using a non-default service manager; and some but
not all system-log-daemon implementations, in particular rsyslogd, will
gracefully switch to receiving messages from systemd-journald instead of
listening on /dev/log directly when used on a systemd system
[2] but see also systemd-journal-remote and systemd-netlogd, which also
might qualify as logging daemons, or not, depending what definition
you're using
