Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 19:16:01 +0200
poitr pogo  wrote:

> I agree.
> In perfect world of knowlegable programmers writing software that
> works there is no need for supervisors.
> 
> One can handle errors or leave this for supervisor.
> 
> For me supervisor will always be a tool of a helpless admin.

:-)

Lighten up you guys. I'm not telling you to use supervisors, and I'm
not putting in Halloween Code to force you to use supervisors. I'm not
telling you to to blindly respawn on aircraft navigation systems, Xray
machines, or missile guidance systems.

I'm simply pointing out that supervision systems have some major
conveniences on both desktops and servers, and that these conveniences
widen their appeal beyond helpless admins and 0.0001% of users.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 13:17:52 -0400
Rob Owens  wrote:

> On Fri, Sep 16, 2016 at 12:32 PM, Steve Litt
>  wrote:
> 
> >
> > Does OpenRC do the conditional starts?  
> 
> 
> Yes, it does.  See "The depend function" here:
> http://www.funtoo.org/Package:OpenRC

Nice!

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Rob Owens]

On Fri, Sep 16, 2016 at 12:32 PM, Steve Litt 
wrote:

>
> Does OpenRC do the conditional starts?


Yes, it does.  See "The depend function" here:
http://www.funtoo.org/Package:OpenRC
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[poitr pogo]

I agree.
In perfect world of knowlegable programmers writing software that works
there is no need for supervisors.

One can handle errors or leave this for supervisor.

For me supervisor will always be a tool of a helpless admin.

Regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 12:52:45PM -0400, Steve Litt wrote:

[cut]

> > 
> > But I am sure that 99.% of the users do not need supervisors in
> > 99.% of the cases...
> 
> I wouldn't say 99.%. I think everyone running wpa_supplicant can
> benefit from having it respawnable, because it crashes at the slightest
> excuse, and respawning makes it available whenever needed.
>

Sorry but if wpa_supplicant crashes for whatever reason (something
that I have never experienced so far, to be honest), then it means
that wpa_supplicant is not doing its job properly. The only way for a
program to do its job properly is by *stayng alive* not by
*crashing*.

If a program crashes while doing its job, then you don't need a
supervisor, rather a piece of software which does its job without
crashing. Crashing should not be the norm, ever. And the problem is
not solved by respawning, ever. 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 15:22:25 +0100
KatolaZ  wrote:

> On Fri, Sep 16, 2016 at 03:51:43PM +0200, Didier Kryn wrote:
> 
> [cut]
> 
> > Nobody supervises pid1, OK? So why would the supervisor need to
> > be supervised? It is supposed to be rock solid. Note that it can be
> > barely relaunched by sysvinit in the same way as getty.
> >   
> 
> Yep, but if a supervisor dies, all his children will be orphaned, and
> even if init respawns the supervisor, this might not imply that all
> the supervisor's children are respawn :)
> 
> I personally don't care at all about supervision systems, since I find
> them completely useless in most of the common applications. I have
> written a couple of custom ones, back in the days, but just for really
> mission-critical stuff, where a process failing to do something meant
> potentially damaging costly devices. And in that case the most logical
> thing to do was to have part of the supervision managed by pid1.
> 
> But I am sure that 99.% of the users do not need supervisors in
> 99.% of the cases...

I wouldn't say 99.%. I think everyone running wpa_supplicant can
benefit from having it respawnable, because it crashes at the slightest
excuse, and respawning makes it available whenever needed.

Supervisors have more benefits than just respawning. They're easier to
understand. They're easier to turn on and off in a wide variety of
situations. They're more trackable via ps axjf. With supervisors, you
don't need to deal with PID files. And, perhaps coolest of all, if
you're running processes off a supervisor, you can make your own daemon
simply by writing a program that runs in the foreground, and the
supervisor will "daemonize" it, instead of having to write your program
to doublefork itself.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 15:51:43 +0200
Didier Kryn  wrote:

> Le 16/09/2016 13:15, KatolaZ a écrit :
> > On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:
> >
> > [cut]
> >  
> >>  Steve,
> >>
> >>  I like more and more this idea of separating the tasks:
> >>   - pid1 (sysvinit or whatever) performs one-shot startups and
> >> basic supervision (like for getty),
> >>   - services needing a sophisticated supervisor use a
> >> supervisor which is only a supervisor, not pid1,
> >>   - services which depend on conditions use specialized tools
> >> to wait for these conditions.
> >>  
> > That looks like a great plan, but who will supervise the
> > supervisors? :)
> >
> > I admit this might seem like a stupid comment, at least at first
> > sight, but whenever you introduce a supervision system under unix
> > you most probably end up deciding that the supervision should be
> > delegated to pid1, since pid1 is the only process able to guarantee
> > that supervision will be working, whatever happens.  
>  Nobody supervises pid1, OK? So why would the supervisor need to
> be supervised? It is supposed to be rock solid. Note that it can be
> barely relaunched by sysvinit in the same way as getty.

I can answer that. There are a lot of architectures in which the
supervisor isn't part of PID1, in which case the purist would say it
must be supervised at least enough, by PID1, that PID1 can respawn the
supervisor.
 
SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 12:24:45 +0200
Didier Kryn  wrote:

>  Steve,
> 
>  I like more and more this idea of separating the tasks:
>   - pid1 (sysvinit or whatever) performs one-shot startups and
> basic supervision (like for getty),

sysvinit, right? Spawn your gettys and run the rc files, which run the
supervisor. Is that what you mean?

>   - services needing a sophisticated supervisor use a supervisor 
> which is only a supervisor, not pid1,

This could be daemontools-encore or runit or s6.

>   - services which depend on conditions use specialized tools to 
> wait for these conditions.

Does OpenRC do the conditional starts?

The architecture I had in mind looks something like this:

..   ..
|sysvinit| .--. run as   |runit supvisr or|
|  PID1  |-|OpenRC|--|daemontools or  |
`' `--' daemon   |s6 supervisor   |
  |  |   `'
  |-getty1   `-most processes|-httpd
  |-getty1   |-sshd
  |-...  `-Other respawnables
  `-getty6


I once built the preceding architecture in Manjaro-OpenRC, and it
worked. Regardless of your "init system", it's always an asset to
control your own process supervisor.
 
SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Peter Olson]

> On September 16, 2016 at 9:51 AM Didier Kryn  wrote:
> 
> Le 16/09/2016 13:15, KatolaZ a écrit :
> > On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:
> >
> > [cut]
> >
> >>  Steve,
> >>
> >>  I like more and more this idea of separating the tasks:
> >>   - pid1 (sysvinit or whatever) performs one-shot startups and basic
> >> supervision (like for getty),
> >>   - services needing a sophisticated supervisor use a supervisor which 
> >> is
> >> only a supervisor, not pid1,
> >>   - services which depend on conditions use specialized tools to wait 
> >> for
> >> these conditions.
> >>
> > That looks like a great plan, but who will supervise the supervisors?
> > :)
> >
> > I admit this might seem like a stupid comment, at least at first
> > sight, but whenever you introduce a supervision system under unix you
> > most probably end up deciding that the supervision should be delegated
> > to pid1, since pid1 is the only process able to guarantee that
> > supervision will be working, whatever happens.
>  Nobody supervises pid1, OK? So why would the supervisor need to be 
> supervised? It is supposed to be rock solid. Note that it can be barely 
> relaunched by sysvinit in the same way as getty.
> 
>  Didier

In the spirit of the minimal PID1 in 30 lines of code, I would propose that one 
of the RC tasks spawned by it would be the minimal supervisor in about 30 lines 
of code, which only supervises supervisors and knows how to launch/relaunch 
them.  Failure unlikely.  The OOM killer won't ever see it, right?

It would require a separation in PID1's RC to move supervisable things into the 
other list, or perhaps a way for a PID1 supervisable task to ask for other 
supervision.  Bleah, this could be more clearly expressed :-)

Peter Olson
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 12:16:03PM -0400, Steve Litt wrote:

[cut]

> 
> Hi KatolaZ,
> 
> The preceding paragraph represents a philosophy more than anything
> else. It's the philosophy that your computer must never, ever, for any
> reason ever become unresponsive. You share that philosophy with Laurent
> Bercot, the developer of the s6 (and s6-rc) init systems. He built s6
> such that pid1 can always respawn more stuff: The supervisor is in PID1.
>

Hi Steve,

please don't let me say things that I have not said. I don't share
that philosophy, at all. To be precise, I have said that in 99.%
of the cases supervision is just *useless*. I simply can't see the
point for it.

For those cases in which supervision *really* matters, and I mean,
where a failing process means damage to device, people, experiments,
buildings, etc.  then the only sensible thing is to not use unix, at
all, since it does not have a safe way of providing supervision. If
you *must* to use unix for those critical tasks, then most of the
supervision *has* to be done by pid1.

The rest of your email has been cut out, since it was based on the
assumptions that I actually need a supervisor, which is false, and
that I need help to find a good one, which does not make sense since
the former one is false :)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 12:15:01 +0100
KatolaZ  wrote:

> On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:
> 
> [cut]
> 
> > 
> > Steve,
> > 
> > I like more and more this idea of separating the tasks:
> >  - pid1 (sysvinit or whatever) performs one-shot startups and
> > basic supervision (like for getty),
> >  - services needing a sophisticated supervisor use a supervisor
> > which is only a supervisor, not pid1,
> >  - services which depend on conditions use specialized tools to
> > wait for these conditions.
> >   
> 
> That looks like a great plan, but who will supervise the supervisors?
> :)
> 
> I admit this might seem like a stupid comment, at least at first
> sight, but whenever you introduce a supervision system under unix you
> most probably end up deciding that the supervision should be delegated
> to pid1, since pid1 is the only process able to guarantee that
> supervision will be working, whatever happens.

Hi KatolaZ,

The preceding paragraph represents a philosophy more than anything
else. It's the philosophy that your computer must never, ever, for any
reason ever become unresponsive. You share that philosophy with Laurent
Bercot, the developer of the s6 (and s6-rc) init systems. He built s6
such that pid1 can always respawn more stuff: The supervisor is in PID1.

I don't share this philosophy. I've never had it happen to me, but if
somehow my (non-pid1) supervisor ever dies and I don't have a terminal
on which to rerun it, then PID1 is unreachable, and I have to either
Ctrl+Alt+Del (if it's enabled and I set up PID1 to do the proper thing
with that interrupt), or power cycle the computer. These occur so
rarely that I'm not at all concerned about them.

So instead of using a product like s6, which has a more complex PID1
that does supervision, I use runit or Suckless Init plus
daemontools-encore plus LittKit or whatever, to obtain the tiniest
possible PID1.

It's funny. Both runit and s6 are inspired by daemontools. Both have
similar syntaxes, and if you can get along in one, you can more or less
get along in the other. Like Spanish and Italian. But they address two
different philosophies.

Anyway, your question about who supervises the supervisors to me
indicates your need for s6. And I'm pretty sure that the new s6-rc
can intermix both respawned and oneshot processes. I've used s6 only a
few times, but my impression is it's the Cadillac of the industry. I
don't have the time to make an s6/s6-rc package, but it would be a cool
addition,  assuming it doesn't uninstall the other init systems
installed on the machine.

By the way, s6 and s6-rc appear to be undergoing some pretty heavy
development. Their documentation pages include much more than they did
a year ago.

http://skarnet.org/software/s6-rc/

http://skarnet.org/software/s6/
 
SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 03:51:43PM +0200, Didier Kryn wrote:

[cut]

> Nobody supervises pid1, OK? So why would the supervisor need to be
> supervised? It is supposed to be rock solid. Note that it can be barely
> relaunched by sysvinit in the same way as getty.
> 

Yep, but if a supervisor dies, all his children will be orphaned, and
even if init respawns the supervisor, this might not imply that all
the supervisor's children are respawn :)

I personally don't care at all about supervision systems, since I find
them completely useless in most of the common applications. I have
written a couple of custom ones, back in the days, but just for really
mission-critical stuff, where a process failing to do something meant
potentially damaging costly devices. And in that case the most logical
thing to do was to have part of the supervision managed by pid1.

But I am sure that 99.% of the users do not need supervisors in
99.% of the cases...

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Didier Kryn]

Le 16/09/2016 13:15, KatolaZ a écrit :

On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:

[cut]


 Steve,

 I like more and more this idea of separating the tasks:
  - pid1 (sysvinit or whatever) performs one-shot startups and basic
supervision (like for getty),
  - services needing a sophisticated supervisor use a supervisor which is
only a supervisor, not pid1,
  - services which depend on conditions use specialized tools to wait for
these conditions.


That looks like a great plan, but who will supervise the supervisors?
:)

I admit this might seem like a stupid comment, at least at first
sight, but whenever you introduce a supervision system under unix you
most probably end up deciding that the supervision should be delegated
to pid1, since pid1 is the only process able to guarantee that
supervision will be working, whatever happens.
Nobody supervises pid1, OK? So why would the supervisor need to be 
supervised? It is supposed to be rock solid. Note that it can be barely 
relaunched by sysvinit in the same way as getty.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Dr. Nikolaus Klepp]

Am Freitag, 16. September 2016 schrieb KatolaZ:
> That looks like a great plan, but who will supervise the supervisors?
> :)
The NSA .. or BND ... . If you don't have something to hide, then you have 
nothing to fear ;-)



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:

[cut]

> 
> Steve,
> 
> I like more and more this idea of separating the tasks:
>  - pid1 (sysvinit or whatever) performs one-shot startups and basic
> supervision (like for getty),
>  - services needing a sophisticated supervisor use a supervisor which is
> only a supervisor, not pid1,
>  - services which depend on conditions use specialized tools to wait for
> these conditions.
> 

That looks like a great plan, but who will supervise the supervisors?
:)

I admit this might seem like a stupid comment, at least at first
sight, but whenever you introduce a supervision system under unix you
most probably end up deciding that the supervision should be delegated
to pid1, since pid1 is the only process able to guarantee that
supervision will be working, whatever happens.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Didier Kryn]

Le 16/09/2016 12:02, Steve Litt a écrit :

On Thu, 15 Sep 2016 12:31:28 -1000
Joel Roth  wrote:


emnin...@riseup.net wrote:

Am Mon, 12 Sep 2016 08:31:54 +
schrieb Jaromil :
   

not at all. We even plan to roll out our own openrc package,
ditching the one from Debian which has many problems. Perhaps
what you are hitting is one of them.

For Devuan's Openrc we will follow the design proposed by
upstream and Gentoo's, the maintainer volunteering for this is
Parazyd (also on this list) who works with us at Dyne.org. We
will also use Openrc in our projects and are advocating for it as
the next new standard in Devuan ascii, at the condition of a 100%
smooth transition from sysvinit.

At last, we haven't done anything on the OpenRC package yet so
your problems are entirely caused by the Debian maintainership,
which can't be trusted at all, IMHO

Thanks a lot Jaromil for the info.

It's not - by chance ;) - i could
pickup from somewhere a beta of the OpenRC package you're working
on?

I hate the idea to redo several scripts (i - painfully ;) adapted
from Gentoo to the previous deb version to make them work with the
debian crippeled openrc) to make them goable for sysvinit.

In any case, me for one (simple user!), i like a lot the idea to
use the original gentoo style openrc - and i like openrc for its
ease to use.

I'll be interested how this work goes. If I understand
correctly, system startup with Devuanized openrc will be
totally handled for the user, the way it is with sysvinit
now.

To that extent, I'm sure openrc will offer "ease of use",
however going by  the feature set and documentation, openrc
aims at a more comprehensive offering (from
https://en.wikipedia.org/wiki/OpenRC):

 Parallel service startup (optional, in development)[3]
 Process segregation through cgroups
 Per-service resource limits (ulimit)
 Separation of code and configuration (init.d / conf.d)
 Ability to include an unlimited variety of commands beyond basic
"start, stop, and status" Stateful init scripts (is it started
already?) Complex init scripts to start multiple components (Samba
(smbd and nmbd), NFS (nfsd, portmap, etc.)) Automatic dependency
calculation and service ordering Proper integration into
container/virtualization (Linux-VServer, OpenVZ, etc.)[4] Proper
modular architecture and separation of optional components (Cron,
syslog) Expressive and flexible network handling (including VPN,
bridges, etc.) Support for bare-metal bare-dependency servers[5][6]

OOTB support for Samba and NFS (along with being Devuan
default) will definitely win users.

The preceding list looks a heck of a lot like the exact feature list of
systemd. What a feather in our cap if that turns out to be true.

As far as OpenRC's inability to respawn, respawnable apps can be
handled partly by a sysvinit PID1, and partially by running
daemontools-encore, runit or s6 as a daemon spawned by OpenRC.




Steve,

I like more and more this idea of separating the tasks:
 - pid1 (sysvinit or whatever) performs one-shot startups and basic 
supervision (like for getty),
 - services needing a sophisticated supervisor use a supervisor 
which is only a supervisor, not pid1,
 - services which depend on conditions use specialized tools to 
wait for these conditions.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Thu, 15 Sep 2016 12:31:28 -1000
Joel Roth  wrote:

> emnin...@riseup.net wrote:
> > Am Mon, 12 Sep 2016 08:31:54 +
> > schrieb Jaromil :
> >   
> > > not at all. We even plan to roll out our own openrc package,
> > > ditching the one from Debian which has many problems. Perhaps
> > > what you are hitting is one of them.
> > > 
> > > For Devuan's Openrc we will follow the design proposed by
> > > upstream and Gentoo's, the maintainer volunteering for this is
> > > Parazyd (also on this list) who works with us at Dyne.org. We
> > > will also use Openrc in our projects and are advocating for it as
> > > the next new standard in Devuan ascii, at the condition of a 100%
> > > smooth transition from sysvinit.
> > > 
> > > At last, we haven't done anything on the OpenRC package yet so
> > > your problems are entirely caused by the Debian maintainership,
> > > which can't be trusted at all, IMHO  
> > 
> > Thanks a lot Jaromil for the info. 
> > 
> > It's not - by chance ;) - i could
> > pickup from somewhere a beta of the OpenRC package you're working
> > on?
> > 
> > I hate the idea to redo several scripts (i - painfully ;) adapted
> > from Gentoo to the previous deb version to make them work with the
> > debian crippeled openrc) to make them goable for sysvinit.
> > 
> > In any case, me for one (simple user!), i like a lot the idea to
> > use the original gentoo style openrc - and i like openrc for its
> > ease to use.  
> 
> I'll be interested how this work goes. If I understand
> correctly, system startup with Devuanized openrc will be
> totally handled for the user, the way it is with sysvinit
> now.
> 
> To that extent, I'm sure openrc will offer "ease of use",
> however going by  the feature set and documentation, openrc
> aims at a more comprehensive offering (from
> https://en.wikipedia.org/wiki/OpenRC):
> 
> Parallel service startup (optional, in development)[3]
> Process segregation through cgroups
> Per-service resource limits (ulimit)
> Separation of code and configuration (init.d / conf.d)
> Ability to include an unlimited variety of commands beyond basic
> "start, stop, and status" Stateful init scripts (is it started
> already?) Complex init scripts to start multiple components (Samba
> (smbd and nmbd), NFS (nfsd, portmap, etc.)) Automatic dependency
> calculation and service ordering Proper integration into
> container/virtualization (Linux-VServer, OpenVZ, etc.)[4] Proper
> modular architecture and separation of optional components (Cron,
> syslog) Expressive and flexible network handling (including VPN,
> bridges, etc.) Support for bare-metal bare-dependency servers[5][6]
> 
> OOTB support for Samba and NFS (along with being Devuan
> default) will definitely win users. 

The preceding list looks a heck of a lot like the exact feature list of
systemd. What a feather in our cap if that turns out to be true.

As far as OpenRC's inability to respawn, respawnable apps can be
handled partly by a sysvinit PID1, and partially by running
daemontools-encore, runit or s6 as a daemon spawned by OpenRC.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng