On Sat, 4 Jun 2016 11:49:25 +0200 Florian Zieboll <[email protected]> wrote:
> On Sat, 4 Jun 2016 03:27:16 -0400 > Steve Litt <[email protected]> wrote: > > > On Sat, 4 Jun 2016 00:42:46 +0200 > > Florian Zieboll <[email protected]> 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
