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

Re: rc



On Mon, Aug 07, 2000 at 11:27:07PM +0100, Mo McKinlay wrote:
> 
> Some things I've been kicking around:
> 
> - Remote service management
>  
>   This is a tricky issue. There's no real defined protocol for it AFAIK,
>   and things like authentication need very careful consideration. The best
>   thing I could think of would be to have some sort of 'svcd' that's
>   optionally started at some later stage (for a start, it depends on 
>   networking :). That doesn't really need thinking about for a while yet,
>   and I don't even know if it's worthwhile doing.
> 
>   From a network management point of view, though, being able to do:
> 
> $ svc granite:httpd restart
> 
>   Would be imensely useful.

This might script that logs via ssh user init/root, and run correct command.
Or just a packet via net, but then all auth is our task to do.

> - IPC?
> 
>   My thinking was that init should handle all of the service
>   starting/stopping, and that 'svc' would be simple wrapper around an
>   easy-to-use library that communicates with init (and maybe also
>   acts as the client for remote service control).
> 
>   I was aiming for something nice and simple, like:
> 
> int 
> scm_control(const char *hostname, const char *service, scmact_t *action);
>  
>   And 'svc' just calls it thusly:
> 
>   action=SC_START;
>   scm_control(NULL, service_name, &action);
> 
>   ...or whichever.
> 
>   The problem is, I can't figure out the best way to make the client
>   library communicate with init [in a portable way].

Simpliest and portable way is making socket or fifo somewhere in /dev/*.
user init/root group init/root.
Or at constant udp or tcp address, but then we need to do all auth ourselves :-(.
One would just send packet (udp ?) like this :

struct service_control {
  int action_nr;
  char service[256];  
}

> How does this sound? Any suggestions?

Suggostion : we need to consider service stopping before implementing anything.
In particular : stopping restarting and config-reloading metaservices
and services that others depend on.
Does restarting / config-reloading xfs need to restart X ?
Does stopping X stop xfs ? What if some other service depends on xfs
or X is only being restarted (reference counting + restart don't touch it ?).
What if someone make 'svc restart graphical' ?
Or even worse : 'svc config-reload graphical'.
Some parts of graphical metaservice can't reload config w/o restarting
themselves, and others depend on it, so we might end restarting whole X.

We need to invent it, as make doesn't handle such thing at all,
and I don't know if anything does, so this work will be very ``innovative'' :-)



Reply to: