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:l...@diamand.org> Sent: 1/7/2015 12:17 AM To: supervision@list.skarnet.org<mailto:supervision@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.pa...@gmail.com> > Sent: 1/6/2015 10:35 PM > To: Steve Litt<mailto:sl...@troubleshooters.com> > Cc: supervision@list.skarnet.org<mailto:supervision@list.skarnet.org> > Subject: Re: thoughts on rudimentary dependency handling > > > > > >> On Jan 6, 2015, at 4:56 PM, Steve Litt <sl...@troubleshooters.com> wrote: >> >> On Tue, 6 Jan 2015 13:17:39 -0800 >> Avery Payne <avery.p.pa...@gmail.com> wrote: >> >>> On Tue, Jan 6, 2015 at 10:20 AM, Laurent Bercot >>> <ska-supervis...@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. >
