Chris Hofstaedtler wrote: > On Mon, Oct 28, 2024 at 11:04:02AM +0100, Helmut Grohne wrote: > > 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. > > Wouldn't we expect that such containers have systemd (and thus > journald) installed, but nothing will start them (because there is > no init).
Sometimes, but not always. Many application containers will not have an ordinary init system present at all; they'll be launched entirely by the container system, which bind-mounts things from outside the container into the container's filesystem, unshares, and then either serves as a minimal init itself (if the application might do non-trivial things like fork/exec and might need init as a reaper) or directly execs the application (especially if the entire container is mostly going to have only 1 process in it). Debian can't serve *all* of these use cases, in part because of Essential. And there's a limit to the degree that Debian should cater to cases that force-remove essential packages to make small containers, in the absence of a distro-wide effort to reduce Essential. But the use case of slim containers does not inherently require having any init system installed within the container. That said, I think it'd be perfectly reasonable to defer that use case, and focus primarily on the use case of letting packages generally request that /dev/log be provided by something, without requiring users of systemd-journald to install a separate syslog daemon they don't want. A Debian-provided package that's *effectively* an equivs stub saying "install this to assert that something will provide /dev/log" seems pretty reasonable for that. There's no way to assert that the init system providing that is actually *running*, because dependencies can only say what is installed and not what is running, but it's not obvious how to do any *better* than that within the framework of dependencies.
