Howbout the following, exampled for cron and socklog-unix as per
http://smarden.org/runit/faq.html#depends:
======================================
#!/bin/sh
truly_useful_socklog-unix(){
return 0
}
sv start socklog-unix || exit 1
truly_useful_socklog-unix || exit 1
exec cron -f
======================================
The user writes truly_useful_socklog-unix as a function in the run
script. It comes with a stub that returns 0 so that it's a NO-OP
by default.
I'm pretty sure this conforms to James' preference (and mine probably)
that it be done in the config and not in the init program.
To satisfy Laurent's preference, everything but the exec cron -f could
be commented out, and if the user wants to use this, he/she can
uncomment all the rest. Or your run script writing program could have an
option to write the dependencies, or not.
In my 5 minute thought process, the last remaining challenge, and it's
a big one, is to get the right service names for the dependencies, and
that requires a standardized list, because, as far as I know, the
daemontools-inspired inits don't have "provides". Such a list would be
hard enough to develop and have accepted, but <tinfoil_hat>I expect our
friends at Red Hat to start changing the names in order to mess us
up</tinfoil_hat>.
In spite of the challenges, what you're doing here is so valuable that
it *must* be done. I believe that what you're contemplating busts the
whole situation wide open, relieves "upstreams" of all init
responsibility except to declare their dependencies by their official
names, makes it almost trival for any distro to adopt a
daemontools-inspired init, and makes it doable for a modestly smart
user to jumper around their existing init system, if that's what they
want to do.
SteveT
Steve Litt *
http://www.troubleshooters.com/
Troubleshooting Training * Human Performance
On Wed, 7 Jan 2015 11:04:51 +0000
Luke Diamand <luke_at_diamand.org> wrote:
> 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 - 15:23:24 UTC