Hi,
On 8/17/22 21:56, Michael Biebl wrote:
Looking at the package in question
$ cat debian/passwd.tmpfiles
# If a password operation is in progress and we lose power, stale
lockfiles
# can be left behind. Clear them on boot.
r! /etc/gshadow.lock
r! /etc/shadow.lock
r! /etc/passwd.lock
r! /etc/group.lock
r! /etc/subuid.lock
r! /etc/subgid.lock
It appears this particular tmpfile is meant to be run only during boot
and not during the runtime of the system.
I've been thinking about this a bit more and there are basically two use
cases for tmpfiles:
1. Creating files in non-persistent locations (/run) and cleanup (at
boot and via cron job):
One example is the case above.
The dependency on "systemd | systemd-tmpfiles" does not cause tmpfiles
to be processed during boot or normal system operation with
sysvinit-core as the systemd-standalone-tmpfiles package ships no init
script or cron job taking over the function of
systemd-tmpfiles-setup.service and systemd-tmpfiles-clean.timer.
I expect that such tmpfiles could mostly be ignored in init-less
environments such as containers as these usually don't expect cleanup
actions for boot and service startup is handled differently.
With one exception this could be covered by mandating that init systems
must run tmpfiles during boot and packages do not need an explicit
dependency for this to happen.
(Why mandate the init system to do so? Because I do not think we want to
require passwd and other packages to ship an init script just to call
systemd-tmpfiles or reimplement the equivalent behavior in a different way.)
However there is also the issue that tmpfiles should probably be called
on package installation to create the requested files below /run before
the next system reboot; they might be relevant for the service to start.
It might be sufficient to only call systemd-tmpfiles if some init system
is used (i.e., not in the init-less container case) and so also be
covered by the requirement above (it would have to include some
systemd-tmpfiles binary to be available).
Some tmpfiles also include only exception rules for cleanup, for example
gvfsd-fuse-tmpfiles.conf:
x /run/user/*/gvfs
This case does not need an explicit dependency either.
2. Creating files in persistent locations (e.g., /var/cache, /var/lib, ...):
Here it would be enough to create the files once (e.g., during the call
in the maintainer script), but it is nice if there is an easy way to
recreate directories with the right permissions.
This is the case where it might be relevant to call systemd-tmpfiles
even in init-less environments. Therefore an explicit dependency might
be warranted.
I'm not sure how relevant this is in Debian, but expect this to not be
widely used so far.
In conclusion, the unconditional dependency on "systemd |
systemd-tmpfiles" is probably not the best way to proceed.
Ansgar
