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