On Wed, May 8, 2013 at 2:55 PM, Ambroz Bizjak <ambrop7@gmail.com> wrote:
>> Init.d scripts are programs - they could probably do just about anything.
>
> They couldn't monitor a process and restart it when it crashes, as
> specified by the restart options in the unit file. That is, without
> significant modifications in the way OpenRC works, such as adding a
> monitoring process, or hacks such as launching a daemon that monitor
> that process specifically.

Sure. I doubt anybody is suggesting that OpenRC would expand the full
feature set of systemd anyway (if it did the people who don't want to
use systemd would likely fork it back to where it is now anyway).

A unit can support dozens of options, but for the most part you can
get by with just a few.  I'm sure any support across the two systems
would start with the few features that get people 90% of the way
there.

If somebody wants to have their processes propped up, they can install
systemd.  Ditto for launching daemons in containers, implementing
xinetd, and all the other bells and whistles systemd offers.

All we really need to get working from a basic usability standpoint is
stuff like what to launch, what UID/niceness/etc to use, and what the
deps are - the stuff in the typical skeleton init.d script.  Really
all you need is some code at the top of the existing init.d script
that just populates some environment variables based on values
translated from the unit file and then invokes the typical current
logic.

The biggest issue I'd see would be around dependency translation.
Assuming our units use the same names as our existing package init.d
scripts (likely) that isn't a problem in most cases, but dependencies
on targets/etc in systemd might need a little handling.  I'm not
really a systemd guru yet so I'm sure I'm oversimplifying, but as long
as any translation focuses only on what openrc already supports it
shouldn't be a big problem.

Rich