Bug#727708: The tech ctte isn't considering OpenRC at all
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Nikolaus Rath writes ("Bug#727708: The tech ctte isn't considering OpenRC at all"):
>> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
>> > Thomas, does OpenRC provide a means for do non-forking daemon
>> > startup ?
>> [...]
>>
>> Ian, quoting from your previous evaluation of upstart
>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1499):
> ...
>> I don't see how this is consistent with what you say about
>> OpenRC. Either the lack of features isn't a problem if they can in
>> principle be implemented in the future (in that case, upstart and OpenRC
>> are both viable candidates), or hypothetical features do not matter (in
>> that case this should also hold for upstart).
>
> Firstly, non-forking daemon startup and supervision is less of a
> feature and more of a design decision. I think that doing it from
> scratch in a system which doesn't have it at all involves a lot of
> design decisions and a fair amount of programming work.
>
> Secondly, the features I list as missing for upstart are not IMO
> anywhere near as important.
I see, thanks for the clarification. To me implementing non-forking
startup in OpenRC seems about the same amount of work as implementing
systemd-style socket activation in upstart.
> If you think OpenRC will soon have non-forking daemon startup, then
> excellent. Can you explain to me how it will work ?
I don't think OpenRC is a good candidate for the default init and I
don't know about any plans to implement non-forking startup, so I'd
rather not do that. My actual goal was to have you reconsider the weight
you put on not-yet-implemented-but-easy-to-do features in upstart :-).
Best,
Nikolaus
--
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C
»Time flies like an arrow, fruit flies like a Banana.«
Reply to: