Hi Sean,
On Sun, Nov 03, 2024 at 03:20:43PM +0800, Sean Whitton wrote:
> Hello,
>
> On Mon 28 Oct 2024 at 11:04am +01, Helmut Grohne wrote:
>
> > Thank you for bringing this up. Despite the little confusion in the end
> > that Chris remarked, I think this practically covers the four cases.
> >
> > However, I think there is a fifth case that is becoming more and more
> > practically relevant. Both docker and podman now have a logging driver
> > called journald.
> >
> > https://docs.docker.com/engine/logging/drivers/journald/
> >
> > I'm not yet sure exactly how this works, but the context is "slim"
> > containers (i.e. those that do not run systemd as pid 1) and I very much
> > expect them to not run a journald from the container environment either.
> > Rather the container runtime essentially provides /dev/log and a
> > journald socket to the container in some (unspecified?) way.
> >
> > This kinda is similar to dbconfig where we have dbconfig-no-thanks. We'd
> > need another package syslog-no-thanks that would have the same provides
> > and conflicts but no systemd dependency now.
> >
> > Of course just adding such a package would result in apt selecting it
> > whenever systemd is difficult to install. In effect, adding such a
> > package would render dependencies on system-log-daemon meaningless and
> > we could just drop them - which is what has been happening and has
> > resulted in this bug.
> >
> > So now we're running in circles. Effectively, we must decide whether the
> > container use case is more important than the non-systemd case or the
> > other way round. I do not see a way to make both just work in a sane
> > way.
>
> I think I understand what you mean about why a syslog-no-thanks virtual
> package would not be helpful, but I don't understand how the journald
> driver option interacts with my four options.
>
> How do systemd and these journald drivers interact? Aren't we in case
> #1?
Admittedly, my understanding of this is quite shallow as well. Roughly
speaking when we talk about docker/podman we most often imply an
application container (i.e. one not running systemd as pid 1) rather
than a system container (where there are systemd and jounrnald proceses
inside the container). More specifically, if we were talking about
system containers, we could easily install your
systemd-journald-is-syslog package and no problem would arise.
Therefore, I assume we are talking about application containers only. An
application container will not have systemd-sysv and probably not even
systemd installed. As a consequence, systemd-journald-is-syslog cannot
be installed as it would have an unsatisfied dependency. Still the
docker/podman journald driver would ensure that /dev/log and
/run/systemd/journal/socket are present and usable. As such the syslog()
function will work in the sense that the log message will be recorded
somewhere. This is different from your #1 ("No logging facility"). No
installed package provides system-log-daemon even though the semantics
of system-log-daemon are provided by the container runtime. From a
satisfiability point of view, we certainly are in your #1 case, but we'd
like to assert to other packages, that system-log-daemon is available
and we cannot without a syslog-no-thanks package.
To put this another way, we need to gain more clarity about what
system-log-daemon actually means beyond what is recorded in policy:
| a daemon that provides a logging facility for other applications
If the focus of this description is on providing /dev/log as a means to
record log message, we can no longer express this in terms of package
relations, because we can run the same container image with or without
the journald driver and thus have this property differ. This is vaguely
similar to how we cannot depend on the availability of Linux kernel
features or CPU instruction set extensions (even though we do via
isa-support).
If the focus is on the exclusion of alternative logging mechanisms
rather than about the availability of a /dev/log listener, then removing
dependencies on this virtual package (as has been happening) is the
right way forward.
To me, this is a strong clue that we should be updating Debian policy in
some way as the current ambiguity is evidently resulting in incompatible
interpretations. Do you agree with this? If yes, would you clone a
policy bug asking to clarify the meaning of system-log-daemon?
Helmut
