[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

tmpfiles.d and docker images (was Re: opentmpfiles & opensysusers, and its use in the Debian policy)



On Fri, 3 Jan 2020 at 06:29, Simon McVittie <smcv@debian.org> wrote:
On Fri, 03 Jan 2020 at 00:05:10 +0800, Shengjing Zhu wrote:
> The advantages of sysusers.d and tmpfiles.d are that you don't need to
> call some magic scripts.
> You only need to write declarative configuration files.

Individual packages only need to install declarative configuration files,
but the OS distribution infrastructure needs to do something to make
the contents of those configuration files take effect (and, crucially,
know when the implementation has finished running).

On systemd systems, that's approximately:

- run systemd-tmpfiles when a package installs a tmpfiles.d snippet
  (this is added to the package's postinst by dh_installsystemd)

- run systemd-sysusers when a package installs a sysusers.d snippet
  (I don't think we have tools to add this to the postinst yet, because
  packages are currently meant to run adduser --system instead, but
  more-systemd-centric distributions probably already do this in their
  equivalent of the postinst)

- run systemd-tmpfiles during boot (this is systemd-tmpfiles-setup.service,
  part of systemd)

- run systemd-sysusers during boot (this is
  systemd-sysusers.service, part of systemd)

The opentmpfiles and opensysusers packaging will need to arrange to do
something analogous, most likely in cooperation with dh_installsystemd
or some other debhelper step for the first two points, and with LSB init
scripts for the tasks where systemd uses one-shot services.

So in Ubuntu we got this interesting bug https://bugs.launchpad.net/ubuntu/+source/haproxy/+bug/1855140 which can be summarized as saying that haproxy doesn't work out of the box in a docker container, because it installs a tmpfiles.d snippet but nothing processes it (I haven't tried, but I very much expect that the behaviour is the same between Debian and Ubuntu here).

On the face of it, this is a bug in the package: it depends for its operation on a package not listed in Depends but making the package depend on systemd wouldn't actually be very useful for getting it running in docker, for a few reasons. I think it would be better to change debhelper:

 * to add "systemd | opentmpfiles" to misc:Depends whenever a package installs a tmpfiles.d snippet
 * stop checking for -d /run/systemd/system in autoscripts/postinst-init-tmpfiles and check for systemd-tmpfiles / opentmpfiles in $PATH instead (and using the one that is found, obviously)

Obviously there are a few variations on the above, like:

 * splitting a systemd-tmpfiles package out of the systemd package first
 * change systemd(-tmpfiles) and opentmpfiles to Provides: tmpfiles and use alternatives to provide /usr/bin/tmpfiles, have debhelper reference these instead

But the approach I outlined seems simplest and easiest to implement. Does it make sense to people here? I can try to work on a patch (although my perl isn't the greatest).

Cheers,
mwh

Reply to: