Re: RFC: OpenRC as Init System for Debian
Stefan Fritsch <sf@sfritsch.de> writes:
> On Monday 07 May 2012, Gergely Nagy wrote:
>> > well, that's another 10 lines of shell worst case. We haven't
>> > agreed on how exactly to handle it and make it configurable and
>> > stuff (especially as tools like monit cover that niche better)
>>
>> That's one of my issues with any init system that does not have
>> this built in: it needs to be written. And if it needs to be
>> written, in shell...
>>
>> > So, whenever a CGroup becomes empty we trigger a script. That
>> > script now can do ... well ... everything.
>>
>> ...things will go terribly wrong, unless you have a strict control
>> of the init scripts. Which you won't, if packages ship their own,
>> without a central authority that tells them what can and what
>> can't be done.
>>
>> While I dislike certain aspects of systemd, and initially disliked
>> that it got rid of my trusty old shell-based initscripts, it is
>> certainly MUCH harder to screw things up when you're given far
>> less power.
>>
>> When the power is in the system itself, not given to individual
>> scripts, that in my opinion, is much safer in the long run.
>
> but sometimes it is necessary to do unusual things in init scripts to
> properly intregrate a service into the system. How to deal with that?
> Write shell wrappers that are executed from systemd?
If absolutely neccessary, that is an option. So is fixing the service to
play nice and be easy to start from systemd, which would be much more
preferable. Off the top of my head, I can't think of a case where this
latter wouldn't be the better option.
For unusual, but not-horribly-complicated things, you might be able to
get away with ExecStartPre & ExecStartPost and similar. (I abuse these
to open a new VT, and attach gdb to the just started daemon - makes for
very easy debuggability, and would be a pain in the backside to do in
most sysvinit initscripts.)
--
|8]
Reply to: