Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1148719 > unrolled thread

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-04 13:20 +0200
    Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-04 16:10 +0200
      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-05 02:40 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-05 11:00 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-05 13:20 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 17:50 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 18:20 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Bill Allombert <ballombe@debian.org> - 2023-06-13 18:20 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Marco d'Itri <md@Linux.IT> - 2023-06-13 18:40 +0200
                Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Ansgar <ansgar@43-1.org> - 2023-06-13 19:50 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 20:10 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 18:40 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 20:20 +0200
                Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 21:00 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 21:10 +0200
                    Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 21:30 +0200
                      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 23:20 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-05 11:20 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-05 13:20 +0200
      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Helmut Grohne <helmut@subdivi.de> - 2023-06-05 14:20 +0200
      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-06 13:10 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-06 14:10 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-07 05:50 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-07 12:40 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-07 13:00 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-07 12:40 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Mark Hindley <mark@hindley.org.uk> - 2023-06-13 15:10 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Mark Hindley <mark@hindley.org.uk> - 2023-06-13 19:10 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 20:00 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-13 21:50 +0200
                Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 22:00 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-13 22:10 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Ansgar <ansgar@43-1.org> - 2023-06-13 22:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1148838

On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote:
> On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:
> > Another possible mitigation which I haven't previously seen proposed
> > is giving *elogind* a Depends or Recommends on systemd-*-standalone.
> > I think that would work to mitigate the failure mode with (1.) and (B.),
> > and the installed-size argument seems less interesting here because the
> > sort of systems that require elogind are already much larger anyway.
> > Would the elogind maintainers be willing to consider this? Does anyone
> > see a reason why it wouldn't work?
> 
> So to confirm, you think that if the elogind maintainers did this, then
> default-systemd-tmpfiles could point at systemd rather than
> systemd-standalone-tmpfiles, which the systemd maintainers prefer, but
> in addition, there aren't any scenarios in which people's systems are
> likely to be re-arranged when they don't want them to be?

Exactly. My hope is that if we had:

    Package: systemd
    Architecture: linux-any
    Provides: default-systemd-tmpfiles, systemd-tmpfiles
    Conflicts: systemd-tmpfiles
    Replaces: systemd-tmpfiles

    Package: systemd-standalone-tmpfiles
    Architecture: linux-any
    Provides: systemd-tmpfiles
    Conflicts: systemd-tmpfiles
    Replaces: systemd-tmpfiles

    Package: elogind
    Depends: systemd-standalone-tmpfiles        # or Recommends?

    Package: foo-service     # any package that requires tmpfiles.d(5)
    Depends: default-systemd-tmpfiles | systemd-tmpfiles

    # optionally, if someone does the work
    Package: openrc-tmpfiles                    # any other implementation
    Architecture: hurd-any kfreebsd-any
    Provides: default-systemd-tmpfiles, systemd-tmpfiles
    Conflicts: systemd-tmpfiles
    Replaces: systemd-tmpfiles

then the right thing (or at least *a* right thing) would happen in
all cases:

* install foo-service on a systemd-booted system:
  systemd is already installed and the dependency is satisfied

* install foo-service on a sysvinit-booted desktop system with elogind:
  elogind is already installed, therefore systemd-standalone-tmpfiles is
  already installed and the dependency is satisfied, avoiding #1016006 etc.

* install foo-service on a sysvinit-booted headless system with no elogind:
  systemd gets installed as a dependency by default, which is what the
  systemd maintainers would prefer to happen when there are no compelling
  space constraints; but the user can specifically ask for
  systemd-standalone-tmpfiles if that's what they'd prefer

* install foo-service in a container with no init system at all:
  systemd gets installed as a dependency by default, which is what the
  systemd maintainers would prefer to happen when there are no compelling
  space constraints; but the user can specifically ask for
  systemd-standalone-tmpfiles if that's what they'd prefer

* (optionally) install foo-service on hurd-i386:
  openrc-tmpfiles (or whatever) gets installed as a dependency

    smcv

[toc] | [prev] | [next] | [standalone]

#1148844

[Multipart message — attachments visible in raw view] — view raw

On Tue, 6 Jun 2023 11:58:07 +0100 Simon McVittie <smcv@debian.org>
wrote:
> On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote:
> > On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:
> > > Another possible mitigation which I haven't previously seen
proposed
> > > is giving *elogind* a Depends or Recommends on systemd-*-
standalone.
> > > I think that would work to mitigate the failure mode with (1.)
and (B.),
> > > and the installed-size argument seems less interesting here
because the
> > > sort of systems that require elogind are already much larger
anyway.
> > > Would the elogind maintainers be willing to consider this? Does
anyone
> > > see a reason why it wouldn't work?
> > 
> > So to confirm, you think that if the elogind maintainers did this,
then
> > default-systemd-tmpfiles could point at systemd rather than
> > systemd-standalone-tmpfiles, which the systemd maintainers prefer,
but
> > in addition, there aren't any scenarios in which people's systems
are
> > likely to be re-arranged when they don't want them to be?
> 
> Exactly. My hope is that if we had:
> 
>     Package: systemd
>     Architecture: linux-any
>     Provides: default-systemd-tmpfiles, systemd-tmpfiles
>     Conflicts: systemd-tmpfiles
>     Replaces: systemd-tmpfiles
> 
>     Package: systemd-standalone-tmpfiles
>     Architecture: linux-any
>     Provides: systemd-tmpfiles
>     Conflicts: systemd-tmpfiles
>     Replaces: systemd-tmpfiles
> 
>     Package: elogind
>     Depends: systemd-standalone-tmpfiles        # or Recommends?
> 
>     Package: foo-service     # any package that requires
tmpfiles.d(5)
>     Depends: default-systemd-tmpfiles | systemd-tmpfiles
> 
>     # optionally, if someone does the work
>     Package: openrc-tmpfiles                    # any other
implementation
>     Architecture: hurd-any kfreebsd-any
>     Provides: default-systemd-tmpfiles, systemd-tmpfiles
>     Conflicts: systemd-tmpfiles
>     Replaces: systemd-tmpfiles
> 
> then the right thing (or at least *a* right thing) would happen in
> all cases:
> 
> * install foo-service on a systemd-booted system:
>   systemd is already installed and the dependency is satisfied
> 
> * install foo-service on a sysvinit-booted desktop system with
elogind:
>   elogind is already installed, therefore systemd-standalone-tmpfiles
is
>   already installed and the dependency is satisfied, avoiding
#1016006 etc.
> 
> * install foo-service on a sysvinit-booted headless system with no
elogind:
>   systemd gets installed as a dependency by default, which is what
the
>   systemd maintainers would prefer to happen when there are no
compelling
>   space constraints; but the user can specifically ask for
>   systemd-standalone-tmpfiles if that's what they'd prefer
> 
> * install foo-service in a container with no init system at all:

Sounds like a good plan to me.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1148920

Luca Boccassi <bluca@debian.org> writes:

> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index b34c183..30ce013 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -722,6 +722,43 @@ The name of the files and directories installed by binary packages
>  outside the system PATH must be encoded in UTF-8 and should be
>  restricted to ASCII when it is possible to do so.
>  
> +.. _s-tmpfiles.d:
> +
> +tmpfiles.d
> +----------
> +
> +Packages might need additional files or directories to implement their
> +functionality. Directories that are located under ``/var/`` or
> +``/etc/``, and files that are located under ``/var/``, must not be
> +created manually via maintainer scripts, but instead be declaratively
> +defined via the `tmpfiles.d
> +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_
> +interface.

This is an oddly specific list of directories and not at all the
directories that I would have expected to be handled by tmpfiles.d.  My
naive expectation would be that the most common path handled by tmpfiles.d
would be /run, /tmp, and /var/tmp.  I read through the other messages in
this bug but I didn't see the explanation for why those directories in
particular.

Given that neither /var (apart from /var/tmp) nor /etc are transient, I
would have expected packages to simply ship the directories under those
paths that they need in the package.  Why is that not the right approach?
Could you explain when tmpfiles.d should be used instead of shipping the
directory in the package?

> +The ``tmpfiles.d`` file format is defined by the ``systemd`` project, and is
> +guaranteed to be stable. Ideally, such definitions should be defined upstream
> +where applicable, and shipped as they are by Debian packages.
> +
> +Details about the syntax and installation paths for ``tmpfiles.d`` are defined
> +by its `reference implementation's documentation,
> +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_ and will
> +not be redefined here.

I'm clearly missing something, but I was naively expecting this section to
start with something more like this:

    Packages that need to create files or directories in file systems that
    may be deleted on each reboot (for example, ``/run``, ``/tmp``, and
    ``/var/tmp``) should do so via configuration files in the
    ``/usr/lib/tmpfiles.d`` directory. The syntax of those files is
    defined by the `systemd tmpfiles.d documentation
    <https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`__.

However, reading that documentation, it sounds like most of the cases for
other directories are handled by other systemd unit configuration
directives.  We should say that explicitly here and reproduce the list of
other directories that should be handled directly by the unit file if
that's what we want people to do.

What's the plan for creating directories in /run on non-systemd systems?
I had assumed that tmpfiles.d would be used for those directories so that
we can use the same mechanism for both systemd and non-systemd systems,
but it looks like that's not ideal for systemd systems.  Is it safe to use
*both* (e.g.) RuntimeDirectory= *and* tmpfiles.d for the same directory so
that tmpfiles.d is used for non-systemd systems?

> +``tmpfiles.d`` snippets should be detected at package build time by
> +tools such as ``debhelper``, packaged, and the appropriate snippet to
> +call them on installation, upgrade, removal, purge and other steps as
> +required, should be automatically added by helpers such as
> +``dh_installtmpfiles``.

Policy should not say things like this.  It's the job of Policy to define
what those snippets are and be specific.  It's Policy-compliant to not use
debhelper at all (we've had some discussions of changing that, but we
haven't yet).  debhelper is one implementation of Policy (and
additional non-Policy stuff), so we should be defining (at a high level)
what it needs to do and what any non-debhelper parallel implementation
should do.

Also, isn't the most obvious way to implement this to use triggers?  That
runs into the problem that Policy still doesn't have any documentation of
triggers, but (unlike debhelper) we can just require that implementations
of the tmpfiles.d mechanism pick up new files via triggers and do the
right thing, which feels appealing.

> Packages shipping ``tmpfiles.d`` snippets should depend on the
> +appropriate virtual packages in the following order:
> +``default-systemd-tmpfiles | systemd-tmpfiles``.

I read the discussion of this and agree this is the best approach.

> +Init systems are required to integrate with ``tmpfiles.d`` and run the
> +service that applies them on boot, and regularly for cleanup
> +purposes. The documentation for the reference implementation,
> +`systemd-tmpfiles,
> +<https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html>`_
> +explains how to call the program so that the appropriate ``tmpfiles.d``
> +snippets are applied at the appropriate time.

I don't really like being this nonspecific.  Can't we just say
specifically what init systems need to do?  I assume it's something like
"call systemd-tmpfiles --create --boot on boot and systemd-tmpfiles
--clean periodically on some schedule" (what schedule?).

Also, based on the previous discussion, it sounds like we should also say
something about how non-systemd init systems must depend on an
implementation of the tmpfiles.d mechanism.  That's arguably a consequence
of the requirement they integrate with it, but given that the exact
dependencies matter a lot for ensuring nothing weird happens during system
package installation, I think we should spell it out.

> +Instead, :ref:`s-tmpfiles.d` snippets should be shipped, being ideally
> +provided by the upstream sources, if any. For more details about the
> +``tmpfiles.d`` interface, see :ref:`s-tmpfiles.d`.

I personally lean against commenting on what upstream should do.  I think
any maintainer already knows that ideally as much is upstreamed as
possible, it's not Policy's role to say stuff like that (that's more of a
Maintainer's Guide thing), and it tends to prompt people to file weird
bugs or create weird Lintian checks that are unactionable for maintainers
of packages whose upstreams have no intention of providing these files for
whatever reason.

Policy is only about Debian packages.  We're not writing policy for
upstream; there's a wiki page that tries to collect that sort of advice.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1148947

On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> Luca Boccassi <bluca@debian.org> writes:
> > +Packages might need additional files or directories to implement their
> > +functionality. Directories that are located under ``/var/`` or
> > +``/etc/``, and files that are located under ``/var/``, must not be
> > +created manually via maintainer scripts, but instead be declaratively
> > +defined via the `tmpfiles.d
> > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_
> > +interface.
> 
> This is an oddly specific list of directories and not at all the
> directories that I would have expected to be handled by tmpfiles.d.

Sorry, in my previous reading of this bug I had been concentrating on
the mechanics of how to make tmpfiles.d(5) something that maintainers can
rely on if it's convenient/helpful, and I'd missed that Luca is asking
for its use to be mandatory in some cases.

I would personally be inclined to concentrate on making tmpfiles.d(5)
something that we can rely on and encourage the use of where appropriate,
even on non-systemd systems, so that (upstream and downstream) maintainers
can move towards it of their own accord because it's more convenient
than other options, and put aside the question of making it generally a
"should" or "must" for the moment.

I believe (please correct me if I'm wrong) that Luca's intention here
is that this is drawing a line between:

- the static files of the OS: /usr and the /usr-like top-level directories
  (the ones that get merged by the /usr merge), which should be statically
  shipped in packages and managed by dpkg (or on "immutable" systems
  that use image-based/tree-based upgrades, maybe by ostree or casync
  or similar, from an tree originally constructed from dpkg packages)

- this specific system's persistent state: /var and parts of /etc

with the intention of eventually enabling functionality like being
able to do a "factory reset" to the equivalent of a freshly installed
system by deleting (most of) /etc and /var, rebooting, and letting the
OS re-create them from a template below /usr; or doing the equivalent
for individual packages by deleting only their part of /etc and /var.

/etc is somewhere between static files and state, because traditionally
it has been a mixture of files that the sysadmin or installer must provide
(like /etc/passwd); configuration files that are shipped by a package and
can be edited by the sysadmin (like /etc/systemd/logind.conf); and
integration glue that links up one package with another, can in principle
be edited by the sysadmin, but in practice is rarely edited
(like /etc/profile.d/flatpak.sh).

Various upstream projects including systemd have been trying to reduce
the extent to which /etc and /var are included in the data.tar.* of a .deb
or other packaging systems' equivalents, by moving the integration glue
to a /usr-like directory (/lib/udev/rules.d, /usr/share/dbus-1/system.d),
reserving the corresponding /etc directory for sysadmin configuration
(/etc/udev/rules.d, /etc/dbus-1/system.d), and providing a way for the
sysadmin to "mask" any integration files they want the system to ignore.

If we disregard conffiles and configuration files in /etc for the
moment, there are basically three ways for a package to get a file onto
the running system:

- ship it in the data.tar.* of a .deb
- create it from a maintainer script and also during boot
    - maybe via tmpfiles.d(5)
    - or maybe open-coded
- have the package create it at runtime, on-demand
    - this clearly doesn't work if the package's code runs unprivileged
      and relies on root having created a directory for it already

For /usr and the /usr-like directories, shipping files in the .deb is by
far the most common, although a few packages need to create files here
via maintainer scripts or triggers (for example
/usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache which is a summary
of files created by multiple packages, and is updated whenever those
packages are added, removed or changed).

For /run, /tmp and /var/tmp, I think there's consensus that shipping files
in those directories in the .deb is a bug, because at the next reboot,
the file will be deleted, leaving the files that dpkg thinks it's managing
out of sync with the files that actually exist. At the moment, these are
variously created by maintainer scripts, systemd units/init scripts, or the
daemons themselves, with some duplication, and no good way to get an
overview of which packages "own" which locations: dpkg doesn't know anything
about them, and systemd knows about some but not all of them.

tmpfiles.d seems like a good way to keep track of who "owns" those
transient files and directories. I think a Policy "must" is probably too
strong here, but a "should" might be reasonable?

For the persistent parts of /var, several packages ship regular files
(as opposed to directories) in the .deb. I think there might be rough
consensus that doing so is at least a "code smell", but quite a lot of
packages do this, so a Policy "must" certainly seems too strong at this
stage. Legacy policy files for polkitd (<< 0.106) are a notable example.
They're no longer necessary with bookworm's polkitd, and I'm hoping to
get rid of them during the trixie cycle; but historically /var/lib was
the only place supported by polkitd other than /etc, so it was functionally
necessary to ship these files.

Looking at my /var, the TeX family of packages seem to be the heaviest
users of regular files in /var, with /var/lib/tex-common/**/*.{cfg,cnf}.

I think we can safely say that creating the top-level directory
of a package's /var, /run, etc. subdirectory declaratively is more
self-documenting than creating it imperatively, and tmpfiles.d seems
like a perfectly good way to achieve that.

I don't think it's desirable to have wording that could be taken to imply
that packages would be wrong to create files inside those top-level
directories at runtime - that would seem silly (for example I don't
want anyone arguing that because the mariadb maintainer script starts
the server, it's somehow a bug for mariadb to create arbitrary database
tables below /var/lib/mysql).

I also don't think Policy should forbid maintainer scripts using files
inside those tmpfiles-managed directories for their own state. For example,
maintainer scripts should be allowed to create files like
/var/lib/mysql/debian-10.11.flag and
/var/lib/systemd/deb-systemd-helper-enabled/*, even if we want to require
/var/lib/mysql and /var/lib/systemd/deb-systemd-helper-enabled to be
registered in tmpfiles.d(5) so that the sysadmin can discover where they
come from.

>     Packages that need to create files or directories in file systems that
>     may be deleted on each reboot (for example, ``/run``, ``/tmp``, and
>     ``/var/tmp``) should do so via configuration files in the
>     ``/usr/lib/tmpfiles.d`` directory. The syntax of those files is
>     defined by the `systemd tmpfiles.d documentation
>     <https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`__.
> 
> However, reading that documentation, it sounds like most of the cases for
> other directories are handled by other systemd unit configuration
> directives.  We should say that explicitly here and reproduce the list of
> other directories that should be handled directly by the unit file if
> that's what we want people to do.

Hmm, yes. Which of these two policies do the systemd maintainers want?

- If a service has RuntimeDirectory= etc. in its unit, then redundantly
  registering those directories in tmpfiles.d(5) is not required unless
  there is some technical reason to do so

- If a service has RuntimeDirectory= etc. in its unit, then it must
  redundantly register those same directories with tmpfiles.d(5)

Reasons we might want the first of those: "don't repeat yourself", and
letting systemd create the directories as late as possible before starting
the service, and clean them up as early as possible after stopping it.

Reasons we might want the second: if we had the first policy, a sysadmin
wanting to find out who "owns" /var/lib/mystery will need to check both
tmpfiles.d and systemd units; if we had the second, in principle they only
need to check tmpfiles.d. Also, non-systemd init systems won't read
RuntimeDirectory= etc., so if the directory is functionally required for
an LSB init script, it needs to be created some other way, and tmpfiles.d
is a reasonable choice for that other way.

> What's the plan for creating directories in /run on non-systemd systems?
> I had assumed that tmpfiles.d would be used for those directories so that
> we can use the same mechanism for both systemd and non-systemd systems,
> but it looks like that's not ideal for systemd systems.  Is it safe to use
> *both* (e.g.) RuntimeDirectory= *and* tmpfiles.d for the same directory so
> that tmpfiles.d is used for non-systemd systems?

A good question. I would hope that systemd's quality-of-implementation is
sufficient that this is safe for maintainers to do, if there's some reason
why it's useful to do so.

> > +``tmpfiles.d`` snippets should be detected at package build time by
> > +tools such as ``debhelper``, packaged, and the appropriate snippet to
> > +call them on installation, upgrade, removal, purge and other steps as
> > +required, should be automatically added by helpers such as
> > +``dh_installtmpfiles``.
> 
> Also, isn't the most obvious way to implement this to use triggers?

Many packages that want to create directories with tmpfiles.d will
want to start a service (systemd unit or init script), and the service
is quite likely to rely on the tmpfiles.d having been run *first* -
"noawait" triggers are certainly not going to be enough.  Are "await"
triggers sufficient to make this happen?

If we are going to do the equivalent thing with declarative system user
creation via sysusers.d, then the sequence we will need in general is:

1. sysusers.d to create system user _foo
2. tmpfiles.d to create /var/lib/foo owned by _foo
3. systemd units/init scripts that run a daemon as uid _foo and require
   /var/lib/foo to exist already

in exactly that order. Can triggers guarantee that?

> Can't we just say
> specifically what init systems need to do?  I assume it's something like
> "call systemd-tmpfiles --create --boot on boot and systemd-tmpfiles
> --clean periodically on some schedule" (what schedule?).

I think the --create side is the key thing here, and --clean can be
left to quality-of-implementation: it's common for services to require
a directory to exist and have specified ownership, and (I suspect) much
less common for them to require it to have old files cleaned up in a
timely fashion.

    smcv

[toc] | [prev] | [next] | [standalone]

#1148951

On Wed, 7 Jun 2023 at 11:29, Simon McVittie <smcv@debian.org> wrote:
>
> On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> > Luca Boccassi <bluca@debian.org> writes:
> > > +Packages might need additional files or directories to implement their
> > > +functionality. Directories that are located under ``/var/`` or
> > > +``/etc/``, and files that are located under ``/var/``, must not be
> > > +created manually via maintainer scripts, but instead be declaratively
> > > +defined via the `tmpfiles.d
> > > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_
> > > +interface.
> >
> > This is an oddly specific list of directories and not at all the
> > directories that I would have expected to be handled by tmpfiles.d.
>
> Sorry, in my previous reading of this bug I had been concentrating on
> the mechanics of how to make tmpfiles.d(5) something that maintainers can
> rely on if it's convenient/helpful, and I'd missed that Luca is asking
> for its use to be mandatory in some cases.
>
> I would personally be inclined to concentrate on making tmpfiles.d(5)
> something that we can rely on and encourage the use of where appropriate,
> even on non-systemd systems, so that (upstream and downstream) maintainers
> can move towards it of their own accord because it's more convenient
> than other options, and put aside the question of making it generally a
> "should" or "must" for the moment.
>
> I believe (please correct me if I'm wrong) that Luca's intention here
> is that this is drawing a line between:
>
> - the static files of the OS: /usr and the /usr-like top-level directories
>   (the ones that get merged by the /usr merge), which should be statically
>   shipped in packages and managed by dpkg (or on "immutable" systems
>   that use image-based/tree-based upgrades, maybe by ostree or casync
>   or similar, from an tree originally constructed from dpkg packages)
>
> - this specific system's persistent state: /var and parts of /etc
>
> with the intention of eventually enabling functionality like being
> able to do a "factory reset" to the equivalent of a freshly installed
> system by deleting (most of) /etc and /var, rebooting, and letting the
> OS re-create them from a template below /usr; or doing the equivalent
> for individual packages by deleting only their part of /etc and /var.
>
> /etc is somewhere between static files and state, because traditionally
> it has been a mixture of files that the sysadmin or installer must provide
> (like /etc/passwd); configuration files that are shipped by a package and
> can be edited by the sysadmin (like /etc/systemd/logind.conf); and
> integration glue that links up one package with another, can in principle
> be edited by the sysadmin, but in practice is rarely edited
> (like /etc/profile.d/flatpak.sh).
>
> Various upstream projects including systemd have been trying to reduce
> the extent to which /etc and /var are included in the data.tar.* of a .deb
> or other packaging systems' equivalents, by moving the integration glue
> to a /usr-like directory (/lib/udev/rules.d, /usr/share/dbus-1/system.d),
> reserving the corresponding /etc directory for sysadmin configuration
> (/etc/udev/rules.d, /etc/dbus-1/system.d), and providing a way for the
> sysadmin to "mask" any integration files they want the system to ignore.
>
> If we disregard conffiles and configuration files in /etc for the
> moment, there are basically three ways for a package to get a file onto
> the running system:
>
> - ship it in the data.tar.* of a .deb
> - create it from a maintainer script and also during boot
>     - maybe via tmpfiles.d(5)
>     - or maybe open-coded
> - have the package create it at runtime, on-demand
>     - this clearly doesn't work if the package's code runs unprivileged
>       and relies on root having created a directory for it already
>
> For /usr and the /usr-like directories, shipping files in the .deb is by
> far the most common, although a few packages need to create files here
> via maintainer scripts or triggers (for example
> /usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache which is a summary
> of files created by multiple packages, and is updated whenever those
> packages are added, removed or changed).
>
> For /run, /tmp and /var/tmp, I think there's consensus that shipping files
> in those directories in the .deb is a bug, because at the next reboot,
> the file will be deleted, leaving the files that dpkg thinks it's managing
> out of sync with the files that actually exist. At the moment, these are
> variously created by maintainer scripts, systemd units/init scripts, or the
> daemons themselves, with some duplication, and no good way to get an
> overview of which packages "own" which locations: dpkg doesn't know anything
> about them, and systemd knows about some but not all of them.
>
> tmpfiles.d seems like a good way to keep track of who "owns" those
> transient files and directories. I think a Policy "must" is probably too
> strong here, but a "should" might be reasonable?
>
> For the persistent parts of /var, several packages ship regular files
> (as opposed to directories) in the .deb. I think there might be rough
> consensus that doing so is at least a "code smell", but quite a lot of
> packages do this, so a Policy "must" certainly seems too strong at this
> stage. Legacy policy files for polkitd (<< 0.106) are a notable example.
> They're no longer necessary with bookworm's polkitd, and I'm hoping to
> get rid of them during the trixie cycle; but historically /var/lib was
> the only place supported by polkitd other than /etc, so it was functionally
> necessary to ship these files.
>
> Looking at my /var, the TeX family of packages seem to be the heaviest
> users of regular files in /var, with /var/lib/tex-common/**/*.{cfg,cnf}.
>
> I think we can safely say that creating the top-level directory
> of a package's /var, /run, etc. subdirectory declaratively is more
> self-documenting than creating it imperatively, and tmpfiles.d seems
> like a perfectly good way to achieve that.
>
> I don't think it's desirable to have wording that could be taken to imply
> that packages would be wrong to create files inside those top-level
> directories at runtime - that would seem silly (for example I don't
> want anyone arguing that because the mariadb maintainer script starts
> the server, it's somehow a bug for mariadb to create arbitrary database
> tables below /var/lib/mysql).
>
> I also don't think Policy should forbid maintainer scripts using files
> inside those tmpfiles-managed directories for their own state. For example,
> maintainer scripts should be allowed to create files like
> /var/lib/mysql/debian-10.11.flag and
> /var/lib/systemd/deb-systemd-helper-enabled/*, even if we want to require
> /var/lib/mysql and /var/lib/systemd/deb-systemd-helper-enabled to be
> registered in tmpfiles.d(5) so that the sysadmin can discover where they
> come from.

Yes I agree, it was not my intention to forbid or discourage such
cases, quite the opposite. What I wanted to say is: if you are
creating directories/files by hand in a maintainer script, please use
tmpfiles.d instead, or if your service/tool/code can do it instead,
that's fine too. Among the goals that you correctly described above,
there's also the desire to remove as much custom maintainer script
code as possible, and that's what I was aiming at.

> >     Packages that need to create files or directories in file systems that
> >     may be deleted on each reboot (for example, ``/run``, ``/tmp``, and
> >     ``/var/tmp``) should do so via configuration files in the
> >     ``/usr/lib/tmpfiles.d`` directory. The syntax of those files is
> >     defined by the `systemd tmpfiles.d documentation
> >     <https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`__.
> >
> > However, reading that documentation, it sounds like most of the cases for
> > other directories are handled by other systemd unit configuration
> > directives.  We should say that explicitly here and reproduce the list of
> > other directories that should be handled directly by the unit file if
> > that's what we want people to do.
>
> Hmm, yes. Which of these two policies do the systemd maintainers want?
>
> - If a service has RuntimeDirectory= etc. in its unit, then redundantly
>   registering those directories in tmpfiles.d(5) is not required unless
>   there is some technical reason to do so
>
> - If a service has RuntimeDirectory= etc. in its unit, then it must
>   redundantly register those same directories with tmpfiles.d(5)
>
> Reasons we might want the first of those: "don't repeat yourself", and
> letting systemd create the directories as late as possible before starting
> the service, and clean them up as early as possible after stopping it.
>
> Reasons we might want the second: if we had the first policy, a sysadmin
> wanting to find out who "owns" /var/lib/mystery will need to check both
> tmpfiles.d and systemd units; if we had the second, in principle they only
> need to check tmpfiles.d. Also, non-systemd init systems won't read
> RuntimeDirectory= etc., so if the directory is functionally required for
> an LSB init script, it needs to be created some other way, and tmpfiles.d
> is a reasonable choice for that other way.

I would tend toward the first one, for the DynamicUser case - for
clarity, this currently means RuntimeDir and friends are recursively
chowned on the fly. I hope for Trixie we'll get uid mapping done
instead and it will be moot, but it's not implemented yet so trying to
be careful.

Also, note that as mentioned earlier these settings work well when
there is a clear and obvious owner, to whose lifecycle the directory
can be tied to, but there are cases where there's either no service at
all or no clear owner.

[toc] | [prev] | [next] | [standalone]

#1148950

On Wed, 7 Jun 2023 at 04:40, Russ Allbery <rra@debian.org> wrote:
>
> Luca Boccassi <bluca@debian.org> writes:
>
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index b34c183..30ce013 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -722,6 +722,43 @@ The name of the files and directories installed by binary packages
> >  outside the system PATH must be encoded in UTF-8 and should be
> >  restricted to ASCII when it is possible to do so.
> >
> > +.. _s-tmpfiles.d:
> > +
> > +tmpfiles.d
> > +----------
> > +
> > +Packages might need additional files or directories to implement their
> > +functionality. Directories that are located under ``/var/`` or
> > +``/etc/``, and files that are located under ``/var/``, must not be
> > +created manually via maintainer scripts, but instead be declaratively
> > +defined via the `tmpfiles.d
> > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_
> > +interface.
>
> This is an oddly specific list of directories and not at all the
> directories that I would have expected to be handled by tmpfiles.d.  My
> naive expectation would be that the most common path handled by tmpfiles.d
> would be /run, /tmp, and /var/tmp.  I read through the other messages in
> this bug but I didn't see the explanation for why those directories in
> particular.
>
> Given that neither /var (apart from /var/tmp) nor /etc are transient, I
> would have expected packages to simply ship the directories under those
> paths that they need in the package.  Why is that not the right approach?
> Could you explain when tmpfiles.d should be used instead of shipping the
> directory in the package?

It's not only for transient hierarchies as in memory based, but also
for hierarchies that can be blown away and the system is supposed to
recover from. /var is state, and if random things under it are lost,
it should be possible to recover without having to throw away the
whole installation and start over. Of course there will be some
limits, but for the really trivial stuff (ie: "I need to store some
cached data somewhere so I need a directory under /var") it should be
possible to cleanly re-set up in an automated fashion after a reboot.
Not only this, but tmpfiles.d help also enforce that the right
metadata (dac/mac/acl) are set, again without having to reinstall
packages. Also more specifically, for image-based systems we want to
be able to have the vendor tree (ie: content shipped by packages)
restricted to /usr and optionally /etc. One of the goals we have for
Trixie is to no longer ship anything under /var (and /boot) hard-coded
in packages.

So the list of directories there is provided as an example, I can make
it more or less specific as needed.

> > +The ``tmpfiles.d`` file format is defined by the ``systemd`` project, and is
> > +guaranteed to be stable. Ideally, such definitions should be defined upstream
> > +where applicable, and shipped as they are by Debian packages.
> > +
> > +Details about the syntax and installation paths for ``tmpfiles.d`` are defined
> > +by its `reference implementation's documentation,
> > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_ and will
> > +not be redefined here.
>
> I'm clearly missing something, but I was naively expecting this section to
> start with something more like this:
>
>     Packages that need to create files or directories in file systems that
>     may be deleted on each reboot (for example, ``/run``, ``/tmp``, and
>     ``/var/tmp``) should do so via configuration files in the
>     ``/usr/lib/tmpfiles.d`` directory. The syntax of those files is
>     defined by the `systemd tmpfiles.d documentation
>     <https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`__.
>
> However, reading that documentation, it sounds like most of the cases for
> other directories are handled by other systemd unit configuration
> directives.  We should say that explicitly here and reproduce the list of
> other directories that should be handled directly by the unit file if
> that's what we want people to do.

I'd be more than delighted to recommend using
StateDirectory=/RuntimeDirectory= and friends as the first choice, and
can certainly do so. However, note that those work best for cases
where there is a service which is the clear owner (they can be shared,
with some caveats that we are trying to solve upstream if ephemeral
users are used, but still needs an owner), and this is important for
lifetime management (ie: when to delete). There are also cases where
there is no clear service that is the owner and to whose lifecycle the
directory should be tied to, and for that tmpfiles.d is the solution.

> What's the plan for creating directories in /run on non-systemd systems?
> I had assumed that tmpfiles.d would be used for those directories so that
> we can use the same mechanism for both systemd and non-systemd systems,
> but it looks like that's not ideal for systemd systems.  Is it safe to use
> *both* (e.g.) RuntimeDirectory= *and* tmpfiles.d for the same directory so
> that tmpfiles.d is used for non-systemd systems?

I don't think it's safe as they could clash, there are specific
semantics tied to usage of ephemeral users that make it different
enough. Other init systems will simply have to be adapted if we go
that way, eg: the init script should create the directory before
starting the service.

> > +``tmpfiles.d`` snippets should be detected at package build time by
> > +tools such as ``debhelper``, packaged, and the appropriate snippet to
> > +call them on installation, upgrade, removal, purge and other steps as
> > +required, should be automatically added by helpers such as
> > +``dh_installtmpfiles``.
>
> Policy should not say things like this.  It's the job of Policy to define
> what those snippets are and be specific.  It's Policy-compliant to not use
> debhelper at all (we've had some discussions of changing that, but we
> haven't yet).  debhelper is one implementation of Policy (and
> additional non-Policy stuff), so we should be defining (at a high level)
> what it needs to do and what any non-debhelper parallel implementation
> should do.

Ok, it was meant as a way to say "please don't go call things by hand
in your maintainer script and use the integrated tools instead", which
I think is something we do want to say in policy? Any specific wording
you'd prefer? One of the goals here is to reduce custom maintainer
scripts code, if the change results in people adding more to call
tools by hand it's kinda counterproductive.

> Also, isn't the most obvious way to implement this to use triggers?  That
> runs into the problem that Policy still doesn't have any documentation of
> triggers, but (unlike debhelper) we can just require that implementations
> of the tmpfiles.d mechanism pick up new files via triggers and do the
> right thing, which feels appealing.

If you mean that the upstream tools should learn to use triggers, then
obviously that cannot happen, as dpkg triggers are a debianism. If you
mean that debhelper should implement this via triggers - perhaps, but
there is one case that I am slowly working to implement, running
tmpfiles to clean things on purge, where that wouldn't work. I think
I'd prefer to leave this open for now, and see what we come up in the
end on the debhelper side. My intention here was pushing toward using
integrated tools and not writing maintainer scripts by hand, that's
all.

> > Packages shipping ``tmpfiles.d`` snippets should depend on the
> > +appropriate virtual packages in the following order:
> > +``default-systemd-tmpfiles | systemd-tmpfiles``.
>
> I read the discussion of this and agree this is the best approach.
>
> > +Init systems are required to integrate with ``tmpfiles.d`` and run the
> > +service that applies them on boot, and regularly for cleanup
> > +purposes. The documentation for the reference implementation,
> > +`systemd-tmpfiles,
> > +<https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html>`_
> > +explains how to call the program so that the appropriate ``tmpfiles.d``
> > +snippets are applied at the appropriate time.
>
> I don't really like being this nonspecific.  Can't we just say
> specifically what init systems need to do?  I assume it's something like
> "call systemd-tmpfiles --create --boot on boot and systemd-tmpfiles
> --clean periodically on some schedule" (what schedule?).

New command lines options do get added and can be useful, so I'd
rather not specify the exact invocation in policy, as that's going to
go out of date pretty soon.

> Also, based on the previous discussion, it sounds like we should also say
> something about how non-systemd init systems must depend on an
> implementation of the tmpfiles.d mechanism.  That's arguably a consequence
> of the requirement they integrate with it, but given that the exact
> dependencies matter a lot for ensuring nothing weird happens during system
> package installation, I think we should spell it out.

Ok, will add something about that.

> > +Instead, :ref:`s-tmpfiles.d` snippets should be shipped, being ideally
> > +provided by the upstream sources, if any. For more details about the
> > +``tmpfiles.d`` interface, see :ref:`s-tmpfiles.d`.
>
> I personally lean against commenting on what upstream should do.  I think
> any maintainer already knows that ideally as much is upstreamed as
> possible, it's not Policy's role to say stuff like that (that's more of a
> Maintainer's Guide thing), and it tends to prompt people to file weird
> bugs or create weird Lintian checks that are unactionable for maintainers
> of packages whose upstreams have no intention of providing these files for
> whatever reason.
>
> Policy is only about Debian packages.  We're not writing policy for
> upstream; there's a wiki page that tries to collect that sort of advice.

What I meant to say here is, if upstream provides a tmpfiles.d, use
that instead of writing a debian-specific one where possible, to avoid
unnecessary debianisms. Any suggestion on how to you want to see this
worded?

[toc] | [prev] | [next] | [standalone]

#1149478

Simon,

Thanks for your care and insight with this and apologies for the delay in
replying (mails to elogind@packages.debian.org have been held up on a
mailserver).

On Tue, Jun 06, 2023 at 11:58:07AM +0100, Simon McVittie wrote:
> Exactly. My hope is that if we had:
> 
>     Package: systemd
>     Architecture: linux-any
>     Provides: default-systemd-tmpfiles, systemd-tmpfiles
>     Conflicts: systemd-tmpfiles
>     Replaces: systemd-tmpfiles
> 
>     Package: systemd-standalone-tmpfiles
>     Architecture: linux-any
>     Provides: systemd-tmpfiles
>     Conflicts: systemd-tmpfiles
>     Replaces: systemd-tmpfiles
> 
>     Package: elogind
>     Depends: systemd-standalone-tmpfiles        # or Recommends?

In principle and just looking at the dependencies this seems a viable solution.
It is very similar to the way we handle the logind and default-logind virtual
packages.

Mark

[toc] | [prev] | [next] | [standalone]

#1149512

Sean,

On Tue, Jun 13, 2023 at 05:15:15PM +0100, Sean Whitton wrote:
> > In principle and just looking at the dependencies this seems a viable
> > solution.  It is very similar to the way we handle the logind and
> > default-logind virtual packages.
> 
> Thank you for reviewing.  Do you have a rough idea of how long it would
> be until you could confirm that this is viable, and implement it in sid?

There is a new upstream version of elogind[1] that is already packaged in
Devuan[2] although that uncovered up an upstream issue that I am waiting to be
resolved[3]. So, maybe by the end of this month?

However, that is only considering whether the packaging and dependencies can be
made to work (like Simon McVittie, I think they probably can).

I remain much less convinced that there is a consensus for requiring packages to
use tmpfiles.d(5) for /var, /tmp and maybe /etc. The recent thread on
debian-devel demonstrated a range of opinion. Thorsten and Bill have just raised
valid points about chroots.

So, whilst I am happy to test the dependency changes in elogind, enshrining this
as a 'should' in the Policy now seems, at least, premature.

Reading the proposed text as somebody who is particularly interested in
non-systemd systems, I am struck by the inconsistency between

  Init systems other than ``systemd`` should allow providing the same
  functionality as appropriate for each system, for example managing the
  directories from the init script shipped by the package.

and the fact that we no longer expect packages to include init scripts alongside
their systemd units and even accept their removal, even if other interested
people offer to maintain them and provide tested patches.

With best wishes

Mark

[1]  https://qa.debian.org/cgi-bin/watch?pkg=elogind

[2]  https://pkginfo.devuan.org/cgi-bin/package-query.html?c=package&q=elogind=252.9-1~rc1

[3]  https://github.com/elogind/elogind/issues/258

[toc] | [prev] | [next] | [standalone]

#1149518

Mark Hindley <mark@hindley.org.uk> writes:

> I remain much less convinced that there is a consensus for requiring
> packages to use tmpfiles.d(5) for /var, /tmp and maybe /etc.

Well, for /tmp, /var/tmp, and /run, I think this is the right approach,
unless there is some other systemd unit configuration that is even better.
This is also already what we're doing across the archive, which is a
pretty strong indication of consensus.  The alternative for /tmp,
/var/tmp, and /run is to add manual mkdirs to systemd units or init
scripts (that normally then have to be run as root, even when the daemon
doesn't), and that's clearly inferior and a poor technical approach.

Given that, if we want to keep everything working with non-systemd init
systems, they're pretty much going to have to invoke systemd-tmpfiles
during boot or things are going to start breaking just because they're not
tested (or some equivalent; there was some discussion of adding support
for the tmpfiles.d format directly to dpkg so that dpkg is also aware of
what package owns these files).

I am considerably more dubious about /var and /etc in general.  I don't
think there's a consensus for managing files or directories there with
systemd-tmpfiles, and most packages just ship the directories in the
package.  I understand that this is part of the overall goal of making
Linux distributions only ship files in /usr, but the project as a whole
has not signed on to that goal yet.

However, what's being proposed here is something much narrower: we should
not be managing directories in those paths *with mkdir in maintainer
scripts*, and instead should use systemd-tmpfiles in that specific case.
For those rare cases where packages are manually creating directories in
shell instead of shipping them in the package for whatever reason,
switching to systemd-tmpfiles feels like an obviously correct improvement
as long as the maintainer script arranges for systemd-tmpfiles to be
invoked so that it will create the directories.  It allows us to move
something from imperative maintainer scripts that are very hard to analyze
to declarative files that have well-understood semantics and handle all
the edge cases that human-written maintainer scripts tend not to manage.
This change should also be invisible to other init systems since the files
and directories are still being created by the maintainer scripts as
always, just using a different program.

However, the really compelling use of systemd-tmpfiles is for /tmp, /run,
and /var/tmp, replacing all the various hacks and workarounds we have had
for decades to create those files during boot, at least in the cases where
the functionality isn't handled directly by a systemd unit.  It's that
behavior that I think deserves a should.

For the persistent directory case in /var and /etc, I think "encouraged"
(Policy advice) is more appropriate at this point, since creating the
directories in maintainer scripts is not *broken*, and we should not be
making those packages instantly buggy.

> The recent thread on debian-devel demonstrated a range of
> opinion. Thorsten and Bill have just raised valid points about chroots.

I don't understand the point about chroots.  It seemed to be based on a
fundmental misunderstanding of how systemd-tmpfiles works?  Thorsten
seemed to think it was a daemon; it's not.  It's essentially a fancy
version of mkdir + chmod + chown plus some other things that supports a
declarative syntax for specifying what directories should exist.  A good
analogy for a different type of operation would be start-stop-daemon
(except systemd-tmpfiles supports declarative configuration, which is even
better).

> Reading the proposed text as somebody who is particularly interested in
> non-systemd systems, I am struck by the inconsistency between

>   Init systems other than ``systemd`` should allow providing the same
>   functionality as appropriate for each system, for example managing the
>   directories from the init script shipped by the package.

This sort of requirement is exactly what we should be getting rid of by
using systemd-tmpfiles uniformly instead.  We should be trying to minimize
the extra work required to support non-systemd init systems in every
package if we want non-systemd init systems to remain viable, because we
know that work largely won't happen.

So, in other words, I haven't read the latest version of the patch yet,
but if that wording is in there and I'm understanding the context
correctly, I think that's the opposite of what we should be saying and we
should take it out in favor of saying everything should just invoke
systemd-tmpfiles or some equivalent implementation that uses the same
configuration.

If other init systems arrange for systemd-tmpfiles to be run when
appropriate (at boot, mostly), then there is no need to provide fallbacks
via, for instance, init scripts with different functionality than the
systemd units.  This is the whole reason why we did the work to package a
standalone systemd-tmpfiles package that can be used regardless of the
init system.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1149543

[Multipart message — attachments visible in raw view] — view raw

On Tue, 13 Jun 2023 10:55:38 -0700 Russ Allbery <rra@debian.org> wrote:

> >   Init systems other than ``systemd`` should allow providing the same
> >   functionality as appropriate for each system, for example managing the
> >   directories from the init script shipped by the package.
>
> This sort of requirement is exactly what we should be getting rid of
> by
> using systemd-tmpfiles uniformly instead.  We should be trying to
> minimize
> the extra work required to support non-systemd init systems in every
> package if we want non-systemd init systems to remain viable, because
> we
> know that work largely won't happen.
> 
> So, in other words, I haven't read the latest version of the patch
> yet,
> but if that wording is in there and I'm understanding the context
> correctly, I think that's the opposite of what we should be saying
> and we
> should take it out in favor of saying everything should just invoke
> systemd-tmpfiles or some equivalent implementation that uses the same
> configuration.
> 
> If other init systems arrange for systemd-tmpfiles to be run when
> appropriate (at boot, mostly), then there is no need to provide
> fallbacks
> via, for instance, init scripts with different functionality than the
> systemd units.  This is the whole reason why we did the work to
> package a
> standalone systemd-tmpfiles package that can be used regardless of
> the
> init system.

That paragraph is in the context of StateDirectory= and
RuntimeDirectory=. These are unit files options, so it's up to
alternative init systems to provide alternative and integrate them in
the (eventual) init script, just as they are defined in the systemd
unit. I've mentioned those explicitly as you indicated earlier in this
thread:

> However, reading that documentation, it sounds like most of the cases for
> other directories are handled by other systemd unit configuration
> directives.  We should say that explicitly here and reproduce the list of
> other directories that should be handled directly by the unit file if
> that's what we want people to do.

Again, the rationale is: when there is a strong ownership model tied to
an individual service those are best as the lifecycle and permissions
are handled, when there is no owner or no specific owner or particular
metadata requirements then tmpfiles.d are best.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1149544

Luca Boccassi <bluca@debian.org> writes:

> That paragraph is in the context of StateDirectory= and
> RuntimeDirectory=. These are unit files options, so it's up to
> alternative init systems to provide alternative and integrate them in
> the (eventual) init script, just as they are defined in the systemd
> unit. I've mentioned those explicitly as you indicated earlier in this
> thread:

Ah!  Sorry, I did inded not understand the context correctly, and should
have just not replied until I had a chance to read the context.  That's my
fault.

I agree with this statement with respect to systemd unit features.  This
is a consequences of the fact that units are the preferred daemon
configuration and package maintainers are allowed to use its features (GR
2019-002).  We should be encouraging them to use those features correctly
and documenting how to do so, but that necessarily means that init scripts
for use with other init systems will need to provide a version of the same
feature in some other way.  We have had several GRs on this topic, and
Policy does need to follow the outcome of those GRs unless someone
overturns them with another GR.

That being said:

> Again, the rationale is: when there is a strong ownership model tied to
> an individual service those are best as the lifecycle and permissions
> are handled, when there is no owner or no specific owner or particular
> metadata requirements then tmpfiles.d are best.

I still am curious if it's safe to configure the same files in both
tmpfiles.d and in the unit file, because it would make it much easier for
those who want to support other init systems to do so.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1149546

On Tue, 13 Jun 2023 at 20:51, Russ Allbery <rra@debian.org> wrote:
>
> Luca Boccassi <bluca@debian.org> writes:
>
> > That paragraph is in the context of StateDirectory= and
> > RuntimeDirectory=. These are unit files options, so it's up to
> > alternative init systems to provide alternative and integrate them in
> > the (eventual) init script, just as they are defined in the systemd
> > unit. I've mentioned those explicitly as you indicated earlier in this
> > thread:
>
> Ah!  Sorry, I did inded not understand the context correctly, and should
> have just not replied until I had a chance to read the context.  That's my
> fault.
>
> I agree with this statement with respect to systemd unit features.  This
> is a consequences of the fact that units are the preferred daemon
> configuration and package maintainers are allowed to use its features (GR
> 2019-002).  We should be encouraging them to use those features correctly
> and documenting how to do so, but that necessarily means that init scripts
> for use with other init systems will need to provide a version of the same
> feature in some other way.  We have had several GRs on this topic, and
> Policy does need to follow the outcome of those GRs unless someone
> overturns them with another GR.
>
> That being said:
>
> > Again, the rationale is: when there is a strong ownership model tied to
> > an individual service those are best as the lifecycle and permissions
> > are handled, when there is no owner or no specific owner or particular
> > metadata requirements then tmpfiles.d are best.
>
> I still am curious if it's safe to configure the same files in both
> tmpfiles.d and in the unit file, because it would make it much easier for
> those who want to support other init systems to do so.

As long as they both do the exact same thing, the one that runs last
is a no-op, I don't believe there would be any issue. But they have to
be kept in sync, not only w.r.t. directory name, but metadata too (ie:
ownership). See it this way: if the features provided by tmpfiles.d
and unit files (w.r.t. directories) were on a venn diagram, there
would be an intersection, yes, but there would not be a complete
overlap. There are things tmpfiles.d can do, that StateDirectory= and
friends cannot, and vice-versa.
In other words, for your stated goal of helping those who want to
support other init systems, it would only cover a subset of cases -
and these are real world cases, there are many services out there
making use of these features. We cannot be restricted, in terms of
unit files options, to what tmpfiles.d can provide, as that is not
realistic.

This is why I added that paragraph, indicating that other init systems
should provide equivalent functionality (and bear in mind I am not a
policy guru, so if 'should' is the wrong word I can change as needed,
it's perfectly fine as far as I'm concerned if other init systems
simply say, run everything as root and forget about security. It's
their choice what features they provide and I was not intending to
force them to do anything.).

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1149550

On Tue, 2023-06-13 at 12:51 -0700, Russ Allbery wrote:
> I still am curious if it's safe to configure the same files in both
> tmpfiles.d and in the unit file, because it would make it much easier for
> those who want to support other init systems to do so.

Having this configured in two places would at least be confusing for
users: where would users need to change settings? In the unit file? In
the tmpfiles files? Both?

Ansgar

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.bugs.dist

csiph-web