Matthew Melton <mjm@???> wrote:

> What you are describing is a state machine?
> Each run level is a stable state representing what is running (or supposed to be). Something needs to trigger (change of input or "change of runlevel")
> Each stable state has an "init" transition state (starting the services) and an "exit" transition state (stopping the services).

Yes, there are similarities.

> We used describe synchronous state machines in this kind of way in digital electronics. A state is stable unless an input is changed which then triggers a bunch of logic to create the new (internal) stable state and the new outputs. This was a higher level of abstraction before the implementation stage where we described the system in terms of the states (themselves represented by binary numbers) it's inputs and it's outputs.
> Optimization is then performed (using karnaugh maps, Boolean algebra etc...) to create a minimal set of Boolean equations that can be implemented with clocked logic gates.

You're taking me back to university lectures and labs now <shudders>. Though I have built small state machine systems - automating candle machines with a previous hat on, and back when Siemens Logo "mini PLCs" were brand new.

> If you look at the circuit diagram with no other information, it is very difficult to see what the circuit actually does. Building the circuit and powering it up helps a bit and you may be able to see what is actually going on (one state changing to another), but the "why" might not be so obvious. The state machine being the higher level shows various transitions from one state to the other when those occur and what outputs should be active etc. With some descriptive names of the states it might become obvious what is going on.
>
> It seems it is very easy to bog down the higher level of abstraction (run-levels and services) with the implementation details (commands to start and stop services) in the same way. Probably because of a wish to optimize too early: change from one run level 1 where A and B are running to run level 2 where only A is running should only stop B. A should not be stopped and restarted. This starts to get a bit complicated with a large number of states. Throwing dependencies (don’t stop B until C has finished don't start B until A has started ) into the mix and to make this efficient requires a complex bit of software, sometimes simple solutions can be the easier to maintain, especially if they hide the gory implementation details, optimized solutions will probably expose more of the implementation and become harder to follow debug and maintain.
>
> So Init with dirs with individual scripts to stop and services can be viewed at quite a high level and quite easily understood and modified.

Indeed, for all it's warts it's easy to visualise and easy to troubleshoot - prior to "optimisations" getting thrown into the mix. Switching states (runlevels) is really quite simple - stop any services that shouldn't already be stopped (execute any "K" links in the new runlevel that don't exist in the current runlevel) and start any service that isn't already supposed to be running (execute any "S" links in the new runlevel that don't exist in the current runlevel).

I suppose some would argue that there's a "problem to be solved" if (picking something from the air)switching runlevels needs to stop a service providing "foo" and start a different service to provide "foo", but "bar" depends on "foo" and so you need to stop "bar" and start it again. I can't think of a real life example, but I'm sure someone has come up with something that justifies why the current system can't be fixed and must be ripped out in favour of some new and untested system ! In those rare cases, then I suppose it'll mean using an intermediate runlevel - so you can't switch from 4 to 5, you have to switch from 4 to 2 and then to 5.
In my experience, sometimes you just have to accept that some edge cases don't work very well - but it's better to have to fudge around those than to make the entire world suboptimal to cater for them.