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