Hi, On Thu, Apr 23, 2020 at 07:16:54PM +0100, Simon McVittie wrote:
> policy-rc.d and invoke-rc.d are not documented in Policy to be a way to > control what happens after you reboot, and neither sysv-rc nor systemd > runs invoke-rc.d or consults policy-rc.d during normal system boot. Ah, that explains it. I was under the impression that policy-rc.d would also be evaluated during normal boot (but since it is removed after installation, it would do nothing unless the admin added another local one). > Just to make sure I wasn't spreading misinformation, I tested this in > a VM, using sysvinit: Mh, I checked that by reading the scripts, and arrived at the same conclusion. Sorry for the noise. > systemd targets do have a well-defined interface, described in > systemd.target(5) and in the KERNEL COMMAND LINE section of systemd(1). > However, if you are setting up special-purpose targets, that's getting > into OS design rather than sysadmin territory (the line between the two > is of course very blurred, and the difference between a special-purpose OS > and an extensively configured instance of a general-purpose OS is mostly > a matter of point of view). Yes, that's basically what I'd expect people to do in complex installations, and a large part of Debian's role is to enable them to do that. Shipping a system that runs well on single machines is the easy part, and since most of the integration work for that has moved from distributions into systemd, there is little that differentiates us from the others for that use case. > > 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. Simon
