Hi, On Wed, Apr 22, 2020 at 03:09:13PM +0100, Simon McVittie wrote:
> In a systemd-based system, I would achieve the equivalent of #950851 > by telling systemd to start a restricted target that only contains the > services I specifically want, instead of the default 'graphical.target' > (targets are analogous to sysvinit runlevels, but you can have any number > of them). Perhaps runit has, or could have, something similar? Can that be automated through a well-defined interface, to allow sysadmins overseeing larger installations to control this centrally through one of the automation frameworks? The policy-rc.d mechanism is used by invoke-rc.d, which is defined as the appropriate way to start an init script in Policy, so sysadmins have a reasonable expectation that all init scripts use that mechanism. We have two custom implementations in the archive (policy-rcd-declarative and policyrcd-script-zg2), and I'd expect that lots of others exist that are local to installations. As far as I can see, there is no similar mechanism in systemd that allows blanket refusal or logging of unknown services, only masking of known services by name. The method of using a custom target comes closest, is there a namespace of target names that can be used by sysadmins that will never conflict with upstream target names? 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)? Simon
