From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1973 Path: news.gmane.org!not-for-mail From: Charlie Brady Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: sv sometimes won't issue down request (specifically, after 'sv once xxx') Date: Fri, 24 Jul 2009 17:01:52 -0400 (EDT) Message-ID: References: <8F9355C5-C168-4AD7-8B6C-502416E7EECC@zoy.org> <94175859-2733-4ACF-85E9-DD5FF627F23B@zoy.org> <17A739BC-94BA-4611-A523-6978934F0D61@zoy.org> <4A633321.1060207@agilent.com> <4A6A1BCF.9070202@agilent.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: ger.gmane.org 1248469324 9153 80.91.229.12 (24 Jul 2009 21:02:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jul 2009 21:02:04 +0000 (UTC) Cc: supervision@list.skarnet.org To: Earl Chew Original-X-From: supervision-return-2208-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Jul 24 23:01:55 2009 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 1MURtr-0005Or-CB for gcsg-supervision@gmane.org; Fri, 24 Jul 2009 23:01:55 +0200 Original-Received: (qmail 7671 invoked by uid 76); 24 Jul 2009 21:03: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 7658 invoked from network); 24 Jul 2009 21:03:12 -0000 X-X-Sender: charlieb@e-smith.charlieb.ott.istop.com In-Reply-To: <4A6A1BCF.9070202@agilent.com> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1973 Archived-At: On Fri, 24 Jul 2009, Earl Chew wrote: > Charlie Brady wrote: >> Yes it does seem buggy optimisation. >> >> Note that if you simply removed that check, you would change not only the >> 'once' behaviour of sv/runsv, but also the behaviour when multiple 'sv d >> xxx' calls are made on a running service. If the optimisation is not >> re-implemented in runsv, then there will be multiple signals and/or custom >> control scripts run where previously there was only one. > > Are you saying it is prudent to move the optimisation in runsv itself? No, I am saying that it would be imprudent to remove the optimisation in sv without considering this issue. I'd defer to Gerrit on a good solution to the problem you've found. How often do you want to run something once (via 'sv once xxx') and then want to terminate it before it has completed?