[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: enable/disable support in /usr/sbin/service

Stefano Zacchiroli schrieb am Freitag, den 04. März 2011:

> On Wed, Mar 02, 2011 at 11:54:05AM -0800, Steve Langasek wrote:
> > At present there *is* no reliable sysadmin interface for enabling/disabling
> > services.  update-rc.d is not it; many admins have been using 'update-rc.d
> > -f remove' for years, but this is /wrong/ and it is /documented/ that this
> > will cause the links to be readded on package upgrade.  policy-rc.d is not
> > it; the spec for this is bloated and I've never heard of an admin who's ever
> > bothered implementing anything more than a "don't start any services in a
> > chroot" policy using this.  And /etc/default/* isn't it; no consistent
> > variable naming, not implemented for all services (and shouldn't be), so
> > it's not scriptable, so it requires vi.
> > 
> > So the mv command above *is* the current method.  And we're in desperate
> > need of a better one.
> Right, this is the technical problem to solve: find one (handy) method
> to enable/disable services and "bless" it as the recommended one.
> There seems to be a bug report against sysvinit-utils (that package
> which ships /usr/sbin/service) about this already: #545325. I'm cc-ing
> the bug log with this mail. For the bug log reference, this discussion
> started on -devel at
> <http://lists.debian.org/debian-devel/2011/03/msg00035.html>.
> Assuming a kind soul devises a patch for #545325, which shouldn't be
> *that* hard, would that be enough to fix the general problem or would we
> need something else in addition? (beside documentation, of course)
> In particular, considering the possibility of other init systems coming
> (see #591791), would /usr/sbin/service enable/disable still be a proper,
> init-system-independent, abstraction?
I don't see a problem in shipping my own server implementation with file-rc
is neccessary. 


Attachment: signature.asc
Description: Digital signature

Reply to: