Le 16/09/2016 12:02, Steve Litt a écrit :
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.
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
