On Sat, 4 Jun 2016 11:49:25 +0200
Florian Zieboll <f.zieboll@???> wrote:

> On Sat, 4 Jun 2016 03:27:16 -0400
> Steve Litt <slitt@???> wrote:
>
> > On Sat, 4 Jun 2016 00:42:46 +0200
> > Florian Zieboll <f.zieboll@???> wrote:
> >
> > > My experience with init systems is mostly limited sysV init (well,
> > > also busybox and system d). That said, I wonder, what information
> > > any arbitrary init system would need, that can not be delivered
> > > e.g. in a simple XML file, packaged with the daemon.
> >
> > You never, never, NEVER want PID1 to be encumbered with an XML
> > parser. Unless you're OS/x (launchd). What could *possibly* go
> > wrong?
>
>
> Hallo Steve,
>
> you fully got me wrong here: I don't see the xml (or what ever) parser
> in the init system (aka pid1) itself, but to be called by the updating
> routines of the init systems, whenever an additional daemon gets
> installed.

That's fine. Absolutely no problem doing that. In fact, it's a good
idea.


> In other words: ATM, every init system comes packaged with the
> necessary init scripts in their own "proprietary" format. I envision
> this information extracted from the individual init scripts

I would never take on that assignment. Parsing out dependency info from
anything but systemd or Epoch would be a murderous task.

I think we should "mooch" info from the now ubiquitous systemd unit
files to set dependencies for other inits.

Either that, or just let them fly, and see what goes wrong. I've been
using Runit for 6 months now. Among supervised (respawned) processes,
there is no definition of order. Order is indeterminate. And yet,
nothing goes wrong. This is not the result I would have expected from
indeterminate process startup, but this is what happens.

In all daemontools-inspired process supervisors, dependency handling,
if you indeed need it, is just this easy:

==============================================
#!/bin/sh
if ping <should_be_pingable_address>; then
exec /path/to/app_depending_on_network
fi
sleep 1
==============================================

In the preceding, if the ping succeeds, the run script is replaced by
app_depending_on_network. If the ping fails, after 1 second the run
script finishes, at which time or soon after, daemontools will try it
again.

SteveT

Steve Litt
June 2016 featured book: Troubleshooting: Why Bother?
http://www.troubleshooters.com/twb