> -----Original Message-----
> From: Dng [mailto:dng-bounces@lists.dyne.org] On Behalf Of Simon Hobson
> Sent: Friday, February 19, 2016 3:45 PM
> To: dng@???
> Subject: Re: [DNG] Runlevels (Was: Lead BusyBox developer on sysvinit)
>
> Rainer Weikusat <rainerweikusat@???> wrote:
>
> > The abstract definition of 'runlevel' is (as far as I'm aware of it):
> > "Set of processes supposed to be running".
>
> That's what I understand it to be.
>
> > Considering this, one can
> > safely conclude that whatever 'Dennys' did, he certainly didn't to
> > that. A somewhat educated guess could be "he implemented something
> > even more uselessly specialized than the already overcomplicated
> > convention of having 4 distinct 'sets of processes which are supposed
> > to be running' during normal system operation plus maintenance,
> > shutdown and reboot modes".
>
> Indeed.
> I think this is one of those things where one can (to borrow from politics)
> suggest "it (SysVInit style run levels) is the worst option apart from all the
> others" - often used to describe our democratic process.
>
> Personally I don't see any major problem with the current system of
> runlevels. I agree it's not perfect, but it works and is understandable ! For the
> most common setups, it's fairly easy to automate which services should be
> running, and I have to wonder how many system actually use more than 1 (or
> at a pinch, 2) runlevel - I don't think any of mine use more than 1 plus single
> user, though I could see "graphical desktop" and "text console only" as viable
> alternate states for some applications. If you want a non-standard state - it's
> easy to manually enable or disable (start or stop) a service - either by directly
> executing /etc/init.d/${service} or the distro specific wrappers (eg
> "invoke_rc.d" or "service").
>
> The alternative he offers seems to be to have no system of "in this state,
> these services should be running", so the equivalent to "telinit n" is "stop
> service x; stop service y; start service z; start service q" - with a suggestion
> that you can throw a load of commands into a script to stop/start the ones
> you want to go to a particular state.
> That, to me, seems to be putting much the same as a runlevel into a script -
> only in a less maintainable manner. Eg, with SysVInit style runlevels, if we add
> a service that's to run in levels 3,4, 5 then we add "S" links in rc[345].d and "K"
> links in rc[!345].d. Instead, every script used for changing system state must
> be checked and edited if needed which IMO seems to be a harder job -
> especially if it's to be automated during package install/removal.
>
> I suppose you could easily have a number of directories (lets call them, for
> example /etc/rcn.d) and into each one put a load of scripts that either enable
> or disable a service. Then to put the system into a particular state, you have a
> script that executes each script in the chosen directory which itself either
> enables or disables the service. Hmm, sounds vaguely familiar !
>

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).

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.

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.

My 2 pence worth

Matt