On Mon, 17 Feb 2020 at 21:34, Christian Ehrhardt <christian.ehrhardt@canonical.com> wrote:
Hi,There is a bug [1] showcasing an issue failing in a docker container as tmpfiles.d there does nothing.On 6th of December I already wrote to ubuntu-server as part of my daily bug duties and subscribed people to the bug. Not much happened since then, a few small IRC exchanges and the Debian init system GR was resolved, but other than that I didn't hear anything else on the topic.This class of issues we should IMHO solve/ignore/handle in a general and not package specific fashion.I was wondering if anyone on the core-system or systemd side of things has already thought/decided on that class of issues and could chime in on the bug.To everyone - have you seen similar bugs that we should Dup' together in regard to this?
Fun.
On the face of it, the package is buggy. tmpfiles configs are processed by systemd, the package depends on the tmpfiles config being processed -> it should Depend: on systemd. This is not a path forward to having it work in a docker container though.
One way to make this work might be this:
1. have src:systemd make a systemd-tmpfiles binary package that just ships systemd-tmpfiles (upstream has made commitments that systemd-tmpfiles does not depend on systemd running: https://lists.debian.org/debian-devel/2019/12/msg00060.html).
2. Have any package that ship tmpfiles configs depend on this new package and invoke systemd-tmpfiles in postinst (debhelper / dh_installsystemd does in fact arrange for systemd-tmpfiles to be invoked in postinst but only if /run/systemd/system exists, so we'd change that to be unconditional and get something to add systemd-tmpfiles to misc:Depends).
This is a bit sketchy because nothing will process the tmpfiles fragments when the container starts, but /run and /tmp and just regular directories in a docker container (by default anyway) so it might just work (tm).
We should probably coordinate this with Debian. The recent thread "opentmpfiles & opensysusers, and its use in the Debian policy" is somewhat related, maybe I should fork a thread off that.
Cheers,
mwh
