The problem is more to do with finding a nice way to structure things
without it turning into a maze of cobbled-together bits of shell script for
doing random hacks to get things to come up in the right order.
On 7 January 2015 at 10:59, James Powell <james4591_at_hotmail.com> wrote:
> You probably could have it initial a ping or similar callback to the NIS
> with an if/else switch as well for the checks. Target a file, directory, IP
> signal, anything really and if found, start the service, else it exits and
> gets retried.
>
> Sent from my Windows Phone
> ________________________________
> From: Luke Diamand<mailto:luke_at_diamand.org>
> Sent: 1/7/2015 12:17 AM
> To: supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
> Subject: Re: thoughts on rudimentary dependency handling
>
> On 07/01/15 07:05, James Powell wrote:
> > The way I see it is this... Either you have high level dependency
> handling within the service supervision system itself, or you have low
> level dependency handling within the service execution files.
> >
> > Keeping the system as simplified as possible lowers the probability and
> possibility of issues. That's one of the basic rules of UNIX programming.
> >
> > I, personally, don't see a need other than low level handling.
> Systemd/uselessd even does this within the unit files, as does some
> instances of sysvinit/bsdinit by using numbered symlinks for execution
> order or using a master control script.
>
> systemd also has 'wants' directories which add dependencies to a unit in
> much the way that's being suggested here.
>
> sysvinit obviously has all the LSB headers in the init.d files to try to
> express dependencies.
>
> Avery - your suggestion sounds like it ought to be simple to implement
> and reasonably easy to understand for a sys-admin. Perhaps the way to go
> is to suck it and see - it'll perhaps then be more obvious with a real
> implementation if it's worth pursuing.
>
> One small concern would be that it's not enough to simply signal a
> dependency to be "up" - it needs to be actually running and working
> before you can start the dependent service successfully. To take my
> [least-]favourite example, you can't start autofs until ypbind has
> actually contacted the NIS server.
>
>
>
> >
> > Sent from my Windows Phone
> > ________________________________
> > From: Avery Payne<mailto:avery.p.payne_at_gmail.com>
> > Sent: 1/6/2015 10:35 PM
> > To: Steve Litt<mailto:slitt_at_troubleshooters.com>
> > Cc: supervision_at_list.skarnet.org<mailto:supervision_at_list.skarnet.org>
> > Subject: Re: thoughts on rudimentary dependency handling
> >
> >
> >
> >
> >
> >> On Jan 6, 2015, at 4:56 PM, Steve Litt <slitt_at_troubleshooters.com>
> wrote:
> >>
> >> 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.
> >
> > Normally, with hand written scripts, that would be the case. You
> cobble together what is needed and go on your way. But this time things
> are a little different. The project I'm doing uses templates - pre-written
> scripts that turn the various launch issues into variables while using the
> same code. This reduces development time and bugs - write the template
> once, debug it once, and reuse it over and over.
> >
> > The idea for dependencies is that I could write something that looks at
> symlinks in a directory and if the template finds anything, it starts the
> dependency. Otherwise it remains blissfully unaware.
> >
> > The issue that Laurent is arguing for is that by creating such a
> framework - even one as thin and as carefully planned - it shuts out future
> possibilities that would handle this correctly at a very high level,
> without the need to write or maintain this layout. To accommodate this
> possibility and to maximize compatibility, he is arguing to stay with the
> same "service is unaware of its surroundings" that have been a part of the
> design of all the frameworks - let things fail and make the admin fix it.
> There is merit to this, not just because of future expansions, but also
> because it allows the end user (read: SysAdmin) the choice of running
> things. Or long story short, "don't set policy, let the end user decide".
> And I agree; I'm a bit old school about these things and I picked up Linux
> over a decade ago because I wanted choices.
> >
> > But from a practical perspective there isn't anything right now that
> handles dependencies at a global level. The approach of "minimum knowledge
> needed and best effort separation of duty" would give a minimal environment
> for the time being. The design is very decentralized and works at a peer
> level; no service definition knows anything other than what is linked in
> its ./needs directory, and side effects are minimized by trying hard to
> keep separation of duty. Because the scripts are distributed and meant to
> be installed as a whole, I can kinda get away with this because all of the
> dependencies are hard coded out of the box and the assumption is that you
> won't break something by tinkering with the links. But of course this runs
> against the setup that Laurent was discussing. It's also brittle and that
> means something is wrong with the design. It should be flexible.
> >
> > So for now, I will look at having a minimum implementation that starts
> things as needed. But only if the user sets a flag to use that feature.
> This keeps the scripts open for the future while giving a minimum
> functionality today that is relatively "safe". So you don't get dependency
> resolution unless you specifically turn it on. And turning it on comes
> with caveats. It's not a perfect solution, it has potential issues, and the
> user abdicates/delegates some of their decisions to my scripts. A no-no,
> to be sure. But again, that's the user's choice to flip the switch on...
> >
> > Also keep in mind that I'm bouncing ideas off of him and he is looking
> at it from a perspective much different from mine. I'm taking a pragmatic
> approach that helps deal with an old situation - the frameworks would be
> more usable/adoptable if there was a baseline set of service definitions
> that allowed for a wholesale switch over to using them from $(whatever
> you're using now). So it's very pragmatic and legacy and "old school" for
> desktops and servers, and that's something still needed because we still
> have those being used everywhere. It's basically a way to grandfather the
> frameworks in using the current technology by providing all of the missing
> "glue" in the form of service definitions. And unfortunately dependency
> resolution is an old issue that has to be worked out as one of my goals,
> which is to increase ease of use so that people want to switch. Short
> version: it's a stop gap measure to do what I am doing. And it will mostly
> work but only if I am very, very careful.
> >
> > Laurent is (I am guessing) looking at this from an angle that includes
> mobile and embedded devices, slim provisioned virtual machines, and how
> "current" system demands are driving Init/services. This is all bleeding
> edge "the future of tomorrow is now here today" stuff. It's a different
> viewpoint and has different goals. So something will always be slightly
> off between what I am a doing and what he is doing - he's waaaay far ahead
> of me, blazing a trail while I'm fixing up holes in the "here and now".
> But it is still important for me to look into the future and realize where
> things are going. Nothing is forever and things change. So I need to be
> prepared.
> >
> > Hopefully that clears the air a bit with regard to why I am asking and
> Laurent's answers. And my apologies in advance to Laurent if I mis-spoke
> of his intentions. This is all provided to you based on my current views
> at this point in time.
> >
>
>
Received on Wed Jan 07 2015 - 11:04:51 UTC