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

[Russ Allbery]

Thorsten Glaser <t.glaser at tarent.de> writes:
> On Tue, 13 Jun 2023, Russ Allbery wrote:

>> namely if you're running anything in a chroot that needs directories
>> created in /tmp and /run, the chroot either needs to have a persistent
>> /tmp and /run or you have to arrange for it to run at least some init
>> scripts during boot.

> I very much disagree here. Both /tmp and /run are volatile, and for /tmp
> there usually even are cronjobs that delete old files, so programs that
> need anything in there must create it themselves at startup (via wrapper
> scripts if needed) if absent.

Ah, I think I understand what you're getting at.  You're talking about
using the init script of a daemon as this sort of wrapper script for
running it in a chroot, by invoking the init script outside of an init
system as root, but inside the chroot.

This works in some situations when the init script has no other
dependencies, but is going to start bit-rotting because init scripts are
less frequently tested and people are going to forget to add separate code
to handle cases that are already handled by tmpfiles.d or the systemd
unit.  The replacement is to first run systemd-tmpfiles --create in the
chroot and then manually run the init script as before.  That does add an
additional step to the (somewhat rare) case of running daemons in chroots,
but it has the advantage of not having to add runtime code to every
package to create directories (often incorrectly, without handling edge
cases), and it's not that different from what you'd need to do to start
daemons in chroots that have dependencies on other daemons.  (It would
also be easy to add to a generic wrapper script for starting a daemon in a
Debian chroot that does this for you.)

If you're just talking about programs that need temporary directories in
/tmp (not /run, which is owned by root) owned by the same user that the
program is running as, or programs that only run as root creating PID
files in /run, then that is unrelated to this bug so far as I can tell;
nothing we're talking about here changes that behavior, because nothing
needs to be pre-created.

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