Re: Is an init required to obey policy-rc.d during boot ?
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
Reply to: