From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1913 Path: news.gmane.org!not-for-mail From: Aras Vaichas Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Please review my Bluetooth run script Date: Thu, 14 Aug 2008 11:37:49 +1000 Message-ID: <48A38C6D.9070204@magtech.com.au> References: <1775.124.170.84.119.1218624530.squirrel@www.magtech.com.au> <20080813120505.GA11751@skarnet.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1218677889 19391 80.91.229.12 (14 Aug 2008 01:38:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 14 Aug 2008 01:38:09 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-2148-gcsg-supervision=m.gmane.org@list.skarnet.org Thu Aug 14 03:39:01 2008 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1KTRnj-00041d-Dr for gcsg-supervision@gmane.org; Thu, 14 Aug 2008 03:38:55 +0200 Original-Received: (qmail 5565 invoked by uid 76); 14 Aug 2008 01:38:16 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 5554 invoked from network); 14 Aug 2008 01:38:15 -0000 X-VirusChecked: Checked X-Env-Sender: arasv@magtech.com.au X-Msg-Ref: server-8.tower-87.messagelabs.com!1218677871!6210460!1 X-StarScan-Version: 5.5.12.14.2; banners=magtech.com.au,-,- X-Originating-IP: [150.101.126.166] User-Agent: Thunderbird 2.0.0.16 (X11/20080724) In-Reply-To: <20080813120505.GA11751@skarnet.org> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1913 Archived-At: Laurent Bercot wrote: >> What I want to know is if this is the "proper" way to go about it. The >> original Blue-Z startup script starts quite a few daemons all at once, >> and it kills off each of them with a "killall". >> > > The original point of service supervision, what caused it to be > implemented (with daemontools first, then with runit) in the first place, > is that some daemons need to be automatically restarted if something > somehow causes them to die. > > Your current "run script" does not accomplish this. > It starts the various Bluetooth daemons, and kills them, just like a > System V script would do. Those daemons are not supervised; what is > supervised is actually the following script: > > exec sh -c "while [ 1 ]; do sleep 100; done" > > I'm sure you will agree that supervising this script isn't particularly > useful. :) > Oh yeah, I was never happy about that bit. The run script for the bluetooth was a first-pass conversion from the Sys-V model. I used the "mountd" run script as an example of starting multiple daemons from the one place. > My advice would be to have separate services for hcid, sdpd, hidd, > rfcommm (if it's a long-lived daemon), dund, pand and pppd. All those > daemons need to be kept alive and running; as an additional benefit, > you don't have to lose their logs by sending them to /dev/null, you > can make use of runsv's logging facility to send each daemon's log > into its own multilog or whatever your favorite logging system is. > We're running an embedded Linux system, so I was trying to keep the number of running processes to a minimum. I guess the runsv is fairly light? I think I will follow your advice and separate them. As a side note, the logging could be handy during development, but we don't keep any permanent logs because we run a flash filing system. > Then, once you have set up one service for each Bluetooth daemon > that needs to be up, you can have a "bluetooth start" script that > does a "sv up" on all those services at once, and a "bluetooth stop" > script that does a "sv down" on them. And you can even control > each daemon separately if the need arises. > So are you recommending that I use a Sys-V script to start all the runsv services? e.g. case "$1" in start) sv up hcid ... sv up sdpd ;; stop) sv down ... sv down hcid ;;; esac Would I be able to use a runsv style of script to do this? Then I have the same problem with "ending" the run script because the run script doesn't end in a daemon process which is why I had the sleep loop in the original run script. I currently use UDEV to do an "sv up bluetooth" when the Bluetooth device is inserted. I guess I could just as easily do "sv up hcid; sv up sdpd; ... ". No-one actually calls "sv down" because it's an embedded system with no physical user interface, the services are only stopped when the device is power cycled, which is fairly common and expected. Aras ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________