On Fri, 24 Apr 2020 at 12:41:01 +0200, Simon Richter wrote: > On Thu, Apr 23, 2020 at 07:16:54PM +0100, Simon McVittie wrote: [Simon Richter wrote:] > > > Can maintainer scripts expect systemd services to be available (mainly > > > thinking about tmpfilesd here, but there might be others that become > > > relevant in the future)? > > > To be clear about that, there is no tmpfilesd daemon: the d in tmpfiles.d > > stands for directory like rc2.d, not daemon like sshd. On package > > installation, tmpfiles.d fragments are processed by maintainer scripts > > (driven by dh_installtmpfiles), without taking policy-rc.d into account. > > Yes, I stumbled across this mostly because samba now fails to configure on > sysvinit systems because /var/run/samba is missing -- so there is an > expectation the maintainer script has that isn't met anymore. That would be > Policy territory.
I believe the current situation is that tmpfiles.d fragments are only processed by maintainer scripts or during boot if systemd is the current init system, so any package that wants to support being used under a non-systemd init (or with no init at all) cannot rely on tmpfiles.d fragments to have created its transient directories first. If this is something you need, I'd suggest sending a tested patch that creates /run/samba on a just-in-time basis when needed (in the LSB init script, or in the maintainer script if those need it) - I expect that'll involve one line doing a 'mkdir -p' in the right place. However, systemd units *are* entitled to assume that tmpfiles.d has been processed, because tmpfiles.d is part of systemd's documented interface. For example, the dbus system service requires /var/lib/dbus. /lib/systemd/system/dbus.service assumes that a tmpfiles.d fragment to set up /var/lib/dbus has already been processed, but /etc/init.d/dbus cannot make that same assumption, and creates /var/lib/dbus itself if necessary; I believe that's a correct implementation. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269 proposes making tmpfiles.d a recommended interface, but that is not currently Policy. sysusers.d is basically "the same shape" as tmpfiles.d, although current best-practice in Debian is to use adduser rather than relying on sysusers.d. Packages can ship sysusers.d fragments (and for example dbus does), but they won't usually have any practical effect, because adduser ran first. smcv
