Henrique de Moraes Holschuh wrote:
> Anthony Towns wrote:
> > Russ Allbery wrote:
> > > Anthony Towns writes:
> > > > BTW, it occured to me that it seems like a wart that update-rc.d doesn't
> > > > respect policy-rc.d -- as it stands, policy-rc.d can prevent a service
> > > > from (re)starting during install/upgrade, but it'll still start on the
> > > > next boot. Is that just something that never got thought of / done, or
> > > > does it actually make sense?
Initially that caught me offguard. I had disabled a service using
policy-rc.d but it still started on the next boot. Discussion with
parties involved exposed me to the fact of implementation that
policy-rc.d is observed only by invoke-rc.d which was designed for use
within package postinst et al scripts. (Although anything that exists
will be used outside of the original context and therefore there are
people using invoke-rc.d instead of service.) It feels strange to me
that policy-rc.d only prevents starting from within package actions
but not otherwise.
Here it is said update-rc.d does not respect policy-rc.d but I think
maybe that should have been invoke-rc.d since update-rc.d just sets
things up to start while it is invoke-rc.d that actually does it.
> > > Consider, for example, bootstrapping a new system in a local chroot that
> > > will then be deployed as a virtual image. You want policy-rc.d to prevent
> > > starting any daemons from the chroot while you're installing and
> > > configuring packages, but you still want all the service management links
> > > and policy installed as normal so that, after you turn this into a cloud
> > > image, everything will run properly.
> >
> > Thanks, that makes sense.
For me it feels strange to leave policy-rc.d in place for a real boot.
Wouldn't it be better to remove the policy-rc.d when converting it
from a chroot to a full booting system? Otherwise one boots and
policy-rc.d is ignored. Everything starts. But then upgrades later
and nothing is (re)started? That doesn't feel good. I think it would
need to be removed for correct continuing operation. (And if so then
it would be fine to respect it during boot too.)
> > I was thinking more along the lines of:
> >
> > - do the install with policy-rc.d overriding which services are active
> > - once you change your policy (once you've finished bootstrapping), you
> > change or remove policy-rc.d, and continue on your merry way
> >
> > But having update-rc.d obey policy-rc.d would stop that from working
> > right; having /init/ obey policy-rc.d would work fine, but that's just
> > crazy complicated.
> >
> > Followup question: does anyone actually use the detailed features of
> > policy-rc.d or is always used in practice to turn all init scripts off?
>
> I think I heard of someone using them *once*. It is very rare, AFAIK.
Is there any other way to do it? I am not aware of any other way. If
that is the only way then it must be in use by everyone who needs it.
Maybe I am missing a better alternative?
> However, if there is one thing I learned the hard way, is that people who
> use the advanced features don't make themselves or that fact known unless
> you ask. They often don't show up even when you break things for them :-(
(Chuckle!) Agreed. But here I am showing up to be one of those
unrepresented people!
Here is an actual live production policy-rc.d from a system where the
web server is being run inside of a chroot. I think the intention is
obvious. Is there any other way to accomplish this other than using
the policy-rc.d? Trying to manage the startup with update-rc.d
doesn't work until after a package is installed.
Bob
#!/bin/sh
# See /usr/share/doc/sysv-rc/README.policy-rc.d.gz for documentation.
while [ $# -gt 0 ]; do
case $1 in
--list) exit 101 ;;
--quiet) shift ;;
-*) shift ;;
apache2) exit 0 ;;
cron) exit 0 ;;
nullmailer) exit 0 ;;
*) break ;;
esac
done
exit 101
Attachment:
signature.asc
Description: Digital signature