On 20/09/2015 11:12, Laurent Bercot wrote:
Interesting, thanks for the notice. I'll have to download OpenRC and
perform experiments to see exactly what it's doing.
So, I downloaded OpenRC, compiled it - the build process makes a lot
of annoying assumptions, such as "ncurses is there and has
On Sun, Sep 20, 2015 at 12:49 PM, Steve Litt wrote:
> 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
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
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
dow
Colin Booth:
The distinction is specifically thus: ./up is what fires when the
service is brought up, ./down is what fires when the service is
brought down, ./run is what fires when a non-running service is
supposed to be running, and ./finish is when a running service stops.
Just because one
On Sun, 20 Sep 2015 18:41:15 +0200
Laurent Bercot wrote:
> 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 prop
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 kn
On 20/09/2015 18:03, Steve Litt wrote:
That's my point exactly. Unfamiliar with the tool, you read the docs,
keep reading about "down" in two different contexts, get confused, and
say "later days."
You will not read about "down" in two different contexts in the docs.
If you had read the docs,
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 perfor
On Sun, 20 Sep 2015 11:26:00 +0200
Laurent Bercot wrote:
> On 20/09/2015 07:30, Steve Litt wrote:
> > Yes. The use of a file called "down" to tell the system not to run
> > the process, and also the use of a script called "down" to perform
> > an action at the appropriate time, will be holy hell
On 20/09/2015 07:30, Steve Litt wrote:
Yes. The use of a file called "down" to tell the system not to run the
process, and also the use of a script called "down" to perform an
action at the appropriate time, will be holy hell to document, even if
theoretically they cannot both happen in the same
Well generally I hatched the idea in my head when I started looking at how
OpenRC can use stacked runlevels and it made me think of the typical stage-2
script which acts as a master controller script to start the supervisor and
execute everything in the service directory. Because s6 provides a s
On 20/09/2015 05:44, Casper Ti. Vector wrote:
I just read your modification on the blurb page (commit e56e1294), and
found it somehow still lacking: in my experience, dependency is honoured
by OpenRC even with `rc_parallel' enabled; and more than that,
"readiness" (here defined as `exit 0' for a
On 20/09/2015 10:47, Colin Booth wrote:
specifically thus: ./up is what fires when the service is brought up,
./down is what fires when the service is brought down, ./run is what
fires when a non-running service is supposed to be running, and
./finish is when a running service stops.
Exactly.
On Sun, Sep 20, 2015 at 12:15 AM, Casper Ti. Vector
wrote:
> (Accidentally sent to Colin as private mail, reposting verbatim here;
> sorry for the disturbance...)
>
> Well, this naming issue is all about overloading... To circumvent the
> overloading problem, we can also use some other name pairs
On Sun, 20 Sep 2015 15:15:52 +0800
"Casper Ti. Vector" wrote:
> (Accidentally sent to Colin as private mail, reposting verbatim here;
> sorry for the disturbance...)
>
> Well, this naming issue is all about overloading... To circumvent the
> overloading problem, we can also use some other name
This paragraph should be:
> The same reason explains why I think `up'/`down' are worse names:
> because `up'/`down' (in longruns) and `up'/`down' (in oneshots
> currently) seem much less correlated than `run'/`finish' (in longruns)
> and `up'/`down' (in oneshots currently).
(I must be really havi
(Accidentally sent to Colin as private mail, reposting verbatim here;
sorry for the disturbance...)
Well, this naming issue is all about overloading... To circumvent the
overloading problem, we can also use some other name pairs like
`start'/`stop' or `begin'/`end' (Gentoo and LaTeX user here ;).
18 matches
Mail list logo
