Re: RFC: OpenRC as Init System for Debian
(Please try to respect M-F-T, and not Cc: me. If I want a CC, I'll set
M-F-T appropriately, thanks)
Stefan Fritsch <email@example.com> writes:
> On Tue, 8 May 2012, Gergely Nagy wrote:
>>> 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.
> Apart from the fact that requirements will be different on different
> systems. Putting functionality for all possible corner cases into the
> daemon is not sensible for any upstream.
That is what configuration files and similar things are for, I believe.
I'd love to see an example where a complex init script is needed, and
that can't be easily turned into systemd service files (for example). So
far, I was told of two cases where the init script does more than a
simple unit file does: one was nbd-client, which does funky stuff I
dared not try to understand last night, the other is every package that
supports starting multiple instances of the same service.
The latter isn't hard to convert to systemd, and will even be simpler,
as far as I see.
> And the integrator/packager may not want to learn all the funny
> languages that daemons can be written in (ocaml, haskell, java, ruby,
> ...). Besides, init scripts are conf files on Debian for good reasons.
So are unit files and configuration files. If the daemon can't be
configured and started properly without an init script's help, then
something's very broken.
Exceptions do exist, of course, but that falls under the 'absolutely
I'd love to hear about examples though. If for nothing else, than to try
my hands at making them work with systemd, it sounds like an amusing