From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1927 Path: news.gmane.org!not-for-mail From: Alex Efros Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runsv and runsvdir problems Date: Mon, 27 Oct 2008 19:30:48 +0200 Organization: http://powerman.name/ Message-ID: <20081027173048.GB12342@home.power> References: <8e04b5820810271012h3d798033t3599cdc468482c89@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1225128682 13058 80.91.229.12 (27 Oct 2008 17:31:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Oct 2008 17:31:22 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-2162-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Oct 27 18:32:24 2008 connect(): Connection refused 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 1KuVwc-0006BY-Lm for gcsg-supervision@gmane.org; Mon, 27 Oct 2008 18:31:58 +0100 Original-Received: (qmail 9773 invoked by uid 76); 27 Oct 2008 17:31:12 -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 9757 invoked from network); 27 Oct 2008 17:31:12 -0000 Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <8e04b5820810271012h3d798033t3599cdc468482c89@mail.gmail.com> User-Agent: Mutt/1.5.16 (2007-06-09) Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1927 Archived-At: Hi! On Mon, Oct 27, 2008 at 07:12:21PM +0200, Ciprian Dorin Craciun wrote: > * first of all a lot of services are not started by default (by > using the 'down' file), but this doesn't stop runsv to start the > logger => could there be an option to start the loggers only when the > server actually starts? why starting these loggers bother you? they doesn't hurt anything > * if I send HUP to runsvdir /services it sends TERM to runsv > /services/ciprian, which in turn sends TERM to runsvdir > /services/ciprian which breaks, and leaves all my services dangling... > => could there be an option to actually pass the same signal down the > chain? (for example if I send TERM to runsv or runsvdir, it should > send TERM downpath, and so for any other signal, for example USR1, > etc.) you can configure this behaviour - check CUSTOMIZE CONTROL in runsv(8) > * if I want to stop the runsvdir /services it sends the signal to > all its children, but exists immediatly, and this is a problem if I > stop it from an rc.0 or 6 script, because it should wait for all the > children to actually stop; for now it leaves them dangling, and the > unmounting of the file systems breaks... => could there be an option > to actually make runsvdir to wait for it's children? > > * if a process takes to long to terminate (when it receives TERM > signal), it would be nice for runsv to actually send KILL, but this > should be configurable, as I wouldn't like to have runsv kill runsvdir > like this; I usually do this: # Give a chance for all processes for clean exit. # This also will kill all 'runsvdir' and signal all 'runsv' to exit. killall5 -15 # ... some other de-initialization like hwclock --systohc sv force-stop /var/service/* &>/dev/null || : # ... more things to do while services stopping - save sound mixer # state, remember last random, shutdown network interfaces, etc. # Goodbye to everybody... killall5 -9 # unmount and reboot > * (a small annoyance) it would be nice to be able to combine runsv > and runsvdir into a single command, as this would reduce the number of > runsv processes, until I actually need to start a service; why starting these processes bother you? they doesn't hurt anything too really, having small annoyance each time you do `ps` and see a lot of small processes which do nothing useful except keeping all your system services running in reliable way - is fairly acceptable. and you always know how to run all your services in less reliable way with standard /etc/rc.d/* scripts to avoid this annoyance -- WBR, Alex.