Re: Request for Comments: Standardize enabling/disabling of system services
Hi,
On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
> I don't like this idea of RUN=yes variables in /etc/default.
>
> 1.) There is already a documented interface, how to disable a service (i.e.
> renaming the S?? symlinks for that runlevel to K??). Adding another layer to do
> this is just confusing and inconsistent.
> There are tools like sysv-rc-conf which can handle that for you. Enabling a
> service is then as easy as sysv-rc-conf $service on|off
yes, that is true. This concept is however limited in so far that you
cannot decide before installing a certain service, weither it starts
after installation. Which is important if you want to avoid running
wrong/half configured services in your network. Basically the approach
is just to give some more possible choices to the users.
> 2.) It makes the init script useless.
That is definitely not true. The init script still stays a common known
interface to control a given service. The idea just adds another layer
of control.
> I often install services, which I only need from time to time, so I disable them
> via the approach above and can start them on-demand vi /etc/init.d/service.
> A RUN=no will break that.
Hu? How should that break it? You do not need to set RUN_<SERVICE>=no,
if you don't want to. You can still disable the service on boot, by
disabling them via sysv-rc-conf and interface with them via invoke-rc.d.
> Imho the only sane option is, to get rid of those RUN_ variables as much as
> possible and advertise tools like sysv-rc-conf more (or even install them by
> default).
No, because this approach basically does not help anybody.
> There are indeed services though, which should *not* be started by default, as
> e.g. they need to be configured first. But instead of inventing such a RUN_
> variable, the init script could directly check if its prerequisites are given
> and only start in that case. It then can also output a more sane error message,
> telling the user what it is missing and how he can change that.
Well, its no invention, becuase the RUN_ variables already exist. They are
just used inconsistent and every init script re-implements the parsing
of them, instead of doing it in a central place with added benefit.
Best Regards,
Patrick
Reply to: