Re: Built-in ordering

[Steve Litt]

On Sun, 20 Sep 2015 10:49:13 -0700
Avery Payne  wrote:

> Regarding the use of ordering during "stage 1", couldn't you just
> have a single definition for stage 1, run through it to set up
> whatever is needed, then transition to a new system state that
> doesn't include that defintion with (insert system management here)?
> What I am trying to ask is if the down files are really necessary.

If you're willing to have a stage1 and stage2, no, it isn't. I
personally consider the existance of a separate stage1 and stage2 to be
suboptimal, and think the ability to mix ordering of runonce and
runlongs is a good thing that might be essential in some use cases.

So on suckless-init plus daemontools-encore (or s6) plus LittKit, if I
had any stage1 at all, it was just remounting / read-write, running
LittKit lk_prepare script, and then running whatever daemontools-encore
calls their svscanboot program. All the rest happens in what would
normally be called stage 2.

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Re: Built-in ordering

[Laurent Bercot]

On 20/09/2015 18:26, Steve Litt wrote:


Of course, all this could be avoided the LittKit way and just run a
script depositing "down" files before running the supervisor. But the
LittKit way specifically defies Laurent's proposal that PID1 be able to
restart the supervisor (I think).


 I don't know exactly how LittKit does things, but "depositing ./down
files" is the way s6-rc proceeds internally. It does not go against the
principle of the supervision tree being able to restart the service,
because only services that are supposed to be down have a ./down file.
The state where everything is down is temporary, at start; then the
service manager removes ./down files one by one as it brings up the
services.

 PID 1 being able to restart the supervisor is something else: it's
the reason why I disagree with your choice of suckless init.

--
 Laurent

Built-in ordering

[Steve Litt]

Hi all,

It just occurred to me that built-in ordering could be as simple as
making the very first loop, on, for want of a better word, svscanboot,
search for a directory with a file called "mefirst". Upon encountering
that directory, it would execute that directory's run script, which
would perform all the down file kludges or other ordering mechanisms
that the individual user wants.

Of course, if one is going to do an initial dummy loop, one could also
look for a file called "order" in each, whose contents indicate a
number to be sorted in order to get the startup ordering of all
longruns and oneshots. But IMHO that would require *a lot* more change
to the supervisor than simply looking for the first "mefirst"
encountered (and it would be a user error to have more than one
directory with a "mefirst").

Of course, all this could be avoided the LittKit way and just run a
script depositing "down" files before running the supervisor. But the
LittKit way specifically defies Laurent's proposal that PID1 be able to
restart the supervisor (I think).

SteveT

Steve Litt 
August 2015 featured book: Troubleshooting: Just the Facts
http://www.troubleshooters.com/tjust

Re: Built-in ordering

[Avery Payne]

Regarding the use of ordering during "stage 1", couldn't you just have a
single definition for stage 1, run through it to set up whatever is needed,
then transition to a new system state that doesn't include that defintion
with (insert system management here)?  What I am trying to ask is if the
down files are really necessary.