supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Jean-Michel Bruenn <jean.bruenn@ip-minds.de>
To: supervision@list.skarnet.org
Subject: Re: hello - hanging services
Date: Wed, 18 Aug 2010 18:02:05 +0200	[thread overview]
Message-ID: <20100818180205.5be254c7.jean.bruenn@ip-minds.de> (raw)
In-Reply-To: <Pine.LNX.4.64.1008181118260.18955@e-smith.charlieb.ott.istop.com>

On Wed, 18 Aug 2010 11:23:41 -0400 (EDT)
Charlie Brady <charlieb-supervision@budge.apana.org.au> wrote:

> There are many complications that you probably haven't thought of. What 
> would runit do if the hangcheck script itself hangs? How might you 
> compromise the existing functionality of runit by adding this feature? How 
> many race conditions do you introduce?

I understand your thoughts about this, and yes i have thought about
this, too. But let's make it clear: This can happen with runit as it
is now, also: a weird written run-script or a broken log-script might
compromise the existing functionality of runit (if it doesnt, adding a
new variant like a hangcheck-script wouldn't do so neither). I mean:
what happens currently if one of the services which you're trying to
start hangs? I havent tried yet, so i guess only the service which
you're trying to start would be compromised - not whole runit. And this
wouldn't be the case with my suggestion neither.

Last but not Least: it's an optional feature, just like the log stuff -
You can use it, you don't need to. If some users feel like using it
they know about the risks, if there are really any (as explained above).

> IMO you don't need to have this functionality in runit, which is already 
> doing it's specified task well. You want something else to act as a 
> service watchdog. You use another tool to do that - for instance, nagios.

Probably you're right, though i don't exactly understand your
argumentation because: Runit is starting crashed processes (this
shouldn't be the job of an Init-System - the job of an init-system is
starting processes, not making sure that they're up and running -
thats the job of a software-watchdog). BUT: runit is doing exactly
this. Runit is taking care that your service is up and running, by
restarting it if its crashing - By argueing that "checking whether a
service is responding (and thus working) is not the job of runit", you
might also argue that "restarting a crashed job is not runit's job".

To point it out again: It's just "optionally" for users who'd like such
a feature, extending the current functionality of restarting a crashed
process - If you, or someone else, feels like "this could hurt my whole
system" you don't need to use it. This doesn't make such a feature
useless or bad.

And back to topic: i didn't wanted to request such a feature, i was
just asking whether it would be difficult to implement/possible.
Whether developers or users implement something like this, is not up to
me :)

P.S: i get your mails twice, purpose? :-)

Cheers

-- 
Jean-Michel Bruenn <jean.bruenn@ip-minds.de>


  reply	other threads:[~2010-08-18 16:02 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-17 17:08 Jean-Michel Bruenn
     [not found] ` <Pine.LNX.4.64.1008171311210.4362@e-smith.charlieb.ott.istop.com>
2010-08-17 17:24   ` Jean-Michel Bruenn
2010-08-17 17:38     ` Charlie Brady
2010-08-18 10:57       ` Laurent Bercot
2010-08-18 15:06         ` Jean-Michel Bruenn
2010-08-18 15:23           ` Charlie Brady
2010-08-18 16:02             ` Jean-Michel Bruenn [this message]
2010-08-19  5:46               ` Laurent Bercot
2010-08-20 12:24                 ` Nicolás de la Torre
2010-08-20 14:42                   ` Tobia Conforto
2010-08-20 14:59                     ` Charlie Brady
     [not found]                     ` <BB40BB3F77C4402181674BE975669A4F@HEL.local>
2010-08-20 15:11                       ` Rehan
2010-08-20 15:13                         ` Charlie Brady
2010-08-20 15:40                     ` Laurent Bercot

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=20100818180205.5be254c7.jean.bruenn@ip-minds.de \
    --to=jean.bruenn@ip-minds.de \
    --cc=supervision@list.skarnet.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).