On Thu, 15 Sep 2016 12:31:28 -1000 Joel Roth <jo...@pobox.com> wrote:
> emnin...@riseup.net wrote: > > Am Mon, 12 Sep 2016 08:31:54 +0000 > > schrieb Jaromil <jaro...@dyne.org>: > > > > > 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
