From: Mike Bell <mike@mikebell.org>
Subject: Dependencies for runit (again)
Date: Tue, 9 Aug 2005 10:03:50 -0700 [thread overview]
Message-ID: <20050809170349.GF20253@mikebell.org> (raw)
From discussions on some list set up to discuss an alternative init
system for debian, I've garnered three main issues with runit's
current dependency system:
- It's not programmatically parsable, only a human can tell that a rule
at the top of a shell script checking for a given socket is actually
waiting for postgres. Prevents
- It encourages code duplication. The code to check if service X is up
is not in service X's directory, but rather scattered over the run
scripts of the services which depend upon it. [1]
- The "repeatedly exec until service is up" method seems to bother
people.
I believe there may be advantages to considering a "proper" dependency
system for runit.
What I had in mind was firstly the addition of a new shell script in the
service's directory (anyone got a good name?), designed to test whether
the service is currently running. In its absence we would have to rely
on the "it hasn't restarted for a while" method.
Secondly, a new directory in a service directory, named dependencies,
which contains symlinks to other service directories. runsv then ensures
that each of these services is running (by either using the
aforementioned "am I up" test script itself, or by having the runsv of
the service itself use said script and then report the status).
Thirdly, though I'm not certain of the need for this, another directory
like the above describing services which should be taken down along with
the current service.
It's a fairly simple set of changes, but...
- it gets you dependencies which can be machine parsed and managed
easily.
- it moves the detection of a daemon's status into that daemon itself
where it belongs - rather than having it duplicated in each of the
dependencies.
- it allows you to do virtual dependencies (contrived example, daemon X
depends on either mysql or postgresql. Its dependencies simply link to
sql-server rather than either one specifically. Certainly a lot easier
than a mess of shell scripting with logical ors to detect each sql
daemon it can use.)
- it fits better with package management. An upgrade to postgresql may
change the method for detecting if it's up, but with current runit
you'd have to also update every package which depends on postgresql.
- it reduces the spin-and-die people seem to dislike so much about
runit. Particularly for a very complicated setup with a lot of daemons
depending on a single one (directly or indirectly) this could be a
significant reduction.
- probably other things I haven't thought of.
Comments?
next reply other threads:[~2005-08-09 17:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-09 17:03 Mike Bell [this message]
2005-08-09 20:34 ` Stefan Karrmann
2005-08-12 17:25 ` Gerrit Pape
2005-08-12 17:32 ` Paul Jarc
2005-08-13 7:32 ` Gerrit Pape
2005-08-27 19:17 ` Gerrit Pape
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050809170349.GF20253@mikebell.org \
--to=mike@mikebell.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).