On Thu, 14 Nov 2024 at 07:09:03 +0100, Helmut Grohne wrote:
> We basically take for granted
> that every system that is running systemd as pid 1 (container or not) is
> providing logging services.
Indeed, this is a motivating factor for the way systemd implements logging:
the systemd authors want it to be something that the authors of system
services can take for granted as "part of the API", so that authors of
system services aren't all expected to implement their own equivalent of
e.g. /var/log/apache2/, with its own configuration.
Specifically, systemd-as-pid-1 implies that /dev/log, syslog(3), the
sd_journal family of APIs, the sockets in /run/systemd/journal, and even
the stderr of a service with no special configuration are all reasonable
ways to log diagnostic messages, and messages sent to any of those places
will end up in the Journal somehow.
Precisely where Journal messages will end up is a decision for the
sysadmin (a limited-size transient database in /run/log, a larger
database in /var/log/journal that persists across reboots, flat text
files in /var/log, and/or forwarding to a remote log server), but the
only components that need to know which choice the sysadmin has made
here, other than journald itself, are those that directly interact with
the logs behind systemd's back (for example by reading /var/log/syslog).
I think it could be reasonable to say that any fully-bootable
Debian system with an init system should be expected to provide the
non-systemd-specific subset of this interface: a writeable /dev/log and
therefore a working syslog(3), and perhaps also providing some sort of
reasonable stderr to system services by default. Precisely where logs
sent to those places end up is a quality-of-implementation issue, with
answers that could include an in-memory ring buffer, flat text files, a
remote log server, or in the worst case scenario, /dev/null (in which case
the services will still work but their diagnostic messages will be lost).
For Debian systems without an init system - meaning chroots, and "thin"
application containers with no init system, which are essentially the same
concept implemented differently - it is already the case that there is no
dependency that you can add to a package that will guarantee that there is
a working /dev/log. If the chroot/container manager implementation happens
to provide a working /dev/log, then it will continue to work whether
your package has a dependency on system-log-daemon or not. Otherwise,
it will not work, and adding a dependency on system-log-daemon will not
solve that (because a system-log-daemon like rsyslog will be *installed*,
but that doesn't mean anything for whether it is *running*).
smcv
