Re: thoughts on rudimentary dependency handling

From: Steve Litt <slitt_at_troubleshooters.com>
Date: Tue, 6 Jan 2015 19:56:28 -0500

On Tue, 6 Jan 2015 13:17:39 -0800
Avery Payne <avery.p.payne_at_gmail.com> wrote:

> On Tue, Jan 6, 2015 at 10:20 AM, Laurent Bercot
> <ska-supervision_at_skarnet.org
> > wrote:
> >
> >
> > I firmly believe that a tool, no matter what it is, should do what
> > the user wants, even if it's wrong or can't possibly work. If you
> > cannot do what the user wants, don't try to be smart; yell at the
> > user, spam the logs if necessary, and fail. But don't do anything
> > the user has not explicitly told you to do.
> >
>
> And there's the rub. I'm at a crossroad with regard to this because:
>
> 1. The user wants service A to run.
> 2. Service A needs B (and possibly C) running, or it will fail.
>
> Should the service fail because of B and C, even though the user
> wants A up,
>
> or
>
> Should the service start B and C because the user requested A be
> running?

I thought the way to do the latter was like this:

http://smarden.org/runit/faq.html#depends

If every "upstream" simply declared that his program needs B and C
running before his program runs, it's easy to translate that into an sv
start command in the run script.

If "upstreams" declared this stuff, it would also be pretty easy to
write a script, with or without the make command, to do the whole
dependency tree. Given that not every init has "provides" ability,
perhaps a standard list of service names could be distributed. There's
already an /etc/services for port numbers: Maybe there could be
an /etc/servicenames for standard names for services.

SteveT

Steve Litt * http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
Received on Wed Jan 07 2015 - 00:56:28 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:18 UTC