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

Re: LSB specification of runlevels



Alan Shutko writes:
> Steven Hanley <sjh@svana.org> writes:

>> though one command would be better I had thought, so instead of
>> sart-service, stop-service, reload-service, etc
>> 
>> control-services (start|stop|reload|etc) service-name

I don't really care what the exact syntax is.  There is a small
advantage in putting the operation into the command name, as that
increases the proportion of the whole command that can be filled in by
command completion[1] but I don't think this is a decisive factor.

[1] I know some zsh has more sophisticated completion, but not all
    shells do.

> Why not just "service service-name (start|stop|reload|etc)"?  RH has
> it already (just runs scripts in /etc/init.d).  It's shorter than your
> alternatives and it already works elsewhere in the Linux world.

This script doesn't actually do what I described, though.

1) It doesn't know how to handle services that aren't managed via
   /etc/init.d - e.g. xdm-alikes on Redhat, the very example we
   started with.

   (This *isn't* an argument for keeping everything in /etc/init.d -
   that's an implementation detail, and I'm talking about an interface
   here.)

2) It doesn't support multiple implementations of the same service
   e.g. supposing you ran one of xdm, gdm, the kde equivalent
   whatever) from /etc/init.d/ you'd still have to know which was
   installed to be able to start it.

   (Here perhaps I'm guilty of focussing on implementation details,
   rather than the hypothetical reader in the parenthesis above, as
   this one could be solved easily enough in this particular
   implementation with a link.)

3) It doesn't start the dependencies of a service before starting the
   service.  The caller has to start services in the right order,
   the system ought to be able to get this right by itself.

   (The reason that this one isn't an implementation detail is that
   the dependency checking is only valuable if you can rely on it, so
   the interface needs to specify that its always there.)

ttfn/rjk



Reply to: