Re: Standard way to disable services
On Thu, Jul 31, 2008 at 11:02:39AM -0300, Henrique de Moraes Holschuh wrote:
> On Thu, 31 Jul 2008, Guido Günther wrote:
> > Why don't we let sysv-init (at least optionally) use policy-rc.d?
>
> Because that would make policy-rc.d and invoke-rc.d useless crap.
>
> The DESIGN behind invoke-rc.d and policy-rc.d is to help MAINTAINER SCRIPTS
> don't screw up when restarting/starting/stopping services automatically,
> either in the normal system context, or inside special chroots.
>
> They are NOT, and I repeat: **NOT** user-level interfaces. They are an
> abstraction layer for the Debian maintainer scripts, and that's it. You
> can't extend them past that without making them useless for their purpose,
> although you *could* add something like policy-rc.d to sysv-init if you
> wanted. But it must not be policy-rc.d itself.
README.invoke-rc.d currently has:
# There is a provision for a "local initscript policy layer" (read: a call to
# /usr/sbin/policy-rc.d if this executable is present in the local system),
# which allows the local system administrator to control the behaviour of
# invoke-rc.d for every initscript id and action. It is assumed that this
# script is OPTIONAL and will by written and provided by packages other than
# the initscript system (sysvinit and file-rc packages).
this gives at least the impression of a "user interface" in this case
the sysadmin being the user.
We might not want to use policy-rc.d as is in sysvinit of filerc during
startup but we might consider moving these policy decisions "no I don't
want this daemon at startup, yes I want that daemon reloaded after
resume" into a policy layer that is independent of the underlying init
mechanism and which can be queried by the different tools be it during
system startup/shutdown or after/before suspend to/from ram/disk.
Cheers,
-- Guido
Reply to: