* Please review my Bluetooth run script @ 2008-08-13 10:48 arasv 2008-08-13 12:05 ` Laurent Bercot 0 siblings, 1 reply; 4+ messages in thread From: arasv @ 2008-08-13 10:48 UTC (permalink / raw) To: supervision Hi there, I'm using the runit scripts in Busybox v1.11.1. I've pretty well moved all my old init.d scripts over to the runit format and I'm very happy with it. I had a little bit of trouble with my Bluetooth Blue-Z startup script but I have a working version. 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". I've managed to split the old init.d script into a "run" and "finish" script. I also have a "down" file so Bluetooth is only started when a BT dongle is added (triggered via udev). Here is my (simplified!) run script: /etc # cat /etc/sv/bluetooth/run #!/bin/sh set -e PATH=/sbin:/bin:/usr/sbin:/usr/bin [ -e /etc/default/bluetooth ] && . /etc/default/bluetooth # start all the Bluetooth services hcid -f $HCID_CONFIG sdpd hidd $HIDD_OPTIONS --server || true hid2hci --tohci > /dev/null 2>&1 || true rfcomm -f $RFCOMM_CONFIG bind all || true dund $DUND_OPTIONS pand $PAND_OPTIONS # now wait until we are told to finish by sv trap 'exit 2' 1 2 3 15 exec sh -c "while [ 1 ]; do sleep 100; done" exit 0 Here is the finish script: /etc # cat /etc/sv/bluetooth/finish #!/bin/sh set -e killall pppd > /dev/null 2>&1 || true killall pand > /dev/null 2>&1 || true killall dund > /dev/null 2>&1 || true rfcommm release all > /dev/null 2>&1 || true killall hidd > /dev/null 2>&1 || true killall sdpd > /dev/null 2>&1 || true killall hcid > /dev/null 2>&1 || true exit 0 Does this seem reasonable? Aras Vaichas ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Please review my Bluetooth run script 2008-08-13 10:48 Please review my Bluetooth run script arasv @ 2008-08-13 12:05 ` Laurent Bercot 2008-08-14 1:37 ` Aras Vaichas 0 siblings, 1 reply; 4+ messages in thread From: Laurent Bercot @ 2008-08-13 12:05 UTC (permalink / raw) To: supervision > 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. :) In other words, you've successfully converted your System V scripts to the runsv model, but you're not taking advantage of what service supervision can do for you. As is, you'd still be better off using a start/stop SysV script, and do without your akward "bluetooth" service which isn't a real service. 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. 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. -- Laurent ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Please review my Bluetooth run script 2008-08-13 12:05 ` Laurent Bercot @ 2008-08-14 1:37 ` Aras Vaichas 2008-08-14 9:47 ` Laurent Bercot 0 siblings, 1 reply; 4+ messages in thread From: Aras Vaichas @ 2008-08-14 1:37 UTC (permalink / raw) To: supervision 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 ______________________________________________________________________ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Please review my Bluetooth run script 2008-08-14 1:37 ` Aras Vaichas @ 2008-08-14 9:47 ` Laurent Bercot 0 siblings, 0 replies; 4+ messages in thread From: Laurent Bercot @ 2008-08-14 9:47 UTC (permalink / raw) To: supervision > 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? Ah, it's good too see that embedded developers use smart supervision systems and good-quality, small-sized, software. :) The runsv process is quite light, you don't need to worry about it. To be convinced, compile runit statically with the small libc of your choice, and look at the size of the executables and the memory footprints. Note: if you're not using logging at all, and you need to optimize as much as you can, you might consider switching to daemontools. runsv embeds the logging facility, while supervise does not, so I think supervise should be a bit lighter. But it's a very minor optimization, and sticking to runit might give you more benefits. > So are you recommending that I use a Sys-V script to start all the runsv > services? I'm certainly not advocating a SysV scheme. Actually I'm not advocating any scheme at all. A simple one-time script will do. The SysV stuff is an overcomplicated way of running one-time scripts. :) > 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. Well, as I understand it, you want to start your Bluetooth daemons as soon as your embedded thingie is powered: then you don't need to write any script at all. Just have your Bluetooth service directories, with appropriate run scripts, in /var/service or wherever runsvdir is run. runsvdir will spawn runsv processes, which will automatically start your daemons (unless you have "down" files in the service directories). If you need to send rfcomm commands, perform them in the one-time initialization (i.e. /etc/runit/1), since rfcomm is a short-lived program. If you need to send them _after_ the daemons are up, it's a bit trickier; but you should already have devised a way to execute a one-time script once the services have been started, just add your rfcomm lines to that script. -- Laurent ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-08-14 9:47 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-08-13 10:48 Please review my Bluetooth run script arasv 2008-08-13 12:05 ` Laurent Bercot 2008-08-14 1:37 ` Aras Vaichas 2008-08-14 9:47 ` Laurent Bercot
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).