Re: rc

[Tomasz Wegrzanowski <maniek@beer.com>]

On Mon, Aug 07, 2000 at 09:10:41PM +0100, Mo McKinlay wrote:
> I had an idea about developing this for Linux (I wasn't aware some such
> thing existed) - actually inspired by WinNT's "service" handling. The way
> it worked was (briefly):
> 
> - Every service had several states:
>     * Stopped
>     * Starting
>     * Started
>     * Paused
>     * Stopping

Not sure if paused, stopping and starting bring us much.
Most services aren't really pausable (how would you pause gpm, nfs or X ?).

Also starting and stopping can be probably internal to init.

> - Every service could be controlled by a pretty standard command (I used
> the name 'svc' for my test program), which took the syntax:
> 
>   svc NAME [OPERATION]
> 
> Without the OPERATION, it displayed the current state of the service,
> otherwise, OPERATION must be one of:
>      * Start
>      * Stop
>      * Pause
>      * Restart (= unpause ?)

reload-config and real restart (= stop & start) might be useful actions.

> And the configuration was managed by makefile-style files so that services
> could depend on one another - the 'starting' and 'stopping states were
> used primarily when starting/stopping dependencies, in order to prevent
> startup/shutdown loops.

Circular dependencies are bad.
Probably can do without.

Also we will probably need start-a-before-b relation
(gpm should be tarted before X, but X don't depend on gpm nor gpm on X)

And we'll probably also need reversed is-part-of relation
(all mounts can be-part-of virtual filesystem,
 and some package can depend on complete filesystem to be done)

Oh, and conflicts wolud be useful, if you want to test two wob/ftp/*-servers
etc.

> 'Runlevels', as they exist now, were effectively pseudo-services, with
> every service that ran in them being dependencies (I didn't quite get as
> far as doing this bit, so things are still a bit hazy). I decided on named
> runlevels, though, which was a) less confusing for the user b) allowed
> more flexibility (init graphical, init multiuser, etc), and thinking about
> it, c) is more fitting with how HURD goes (imho).

Agree.

> # > When ?
> # 
> # Only good god knows.
> 
> If there's interest, I could start hacking something together - or at
> least, getting a concrete design together?

I'm willing to test it on both GNU/Linux and GNU/Hurd.