On Thu, 15 Sep 2016 12:31:28 -1000
Joel Roth <joelz@???> wrote:
> emninger@??? wrote:
> > Am Mon, 12 Sep 2016 08:31:54 +0000
> > schrieb Jaromil <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
::
Re: [DNG] Openrc
