From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1378 Path: news.gmane.org!not-for-mail From: Gerrit Pape Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: How to kill runsv, no matter what? Date: Fri, 23 Feb 2007 14:05:03 +0000 Message-ID: <20070223140504.17459.qmail@3f646761ee1f68.315fe32.mid.smarden.org> References: <5422d5e60702211214q7ecaf23co838e9ff1b9be32de@mail.gmail.com> <5422d5e60702211304g5051747aoad3dd893abaf0b16@mail.gmail.com> <5422d5e60702221951h1abb7e60l77717192900a63a8@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1172239494 1327 80.91.229.12 (23 Feb 2007 14:04:54 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 23 Feb 2007 14:04:54 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-1614-gcsg-supervision=m.gmane.org@list.skarnet.org Fri Feb 23 15:04:44 2007 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 1HKb2R-00076o-8o for gcsg-supervision@gmane.org; Fri, 23 Feb 2007 15:04:43 +0100 Original-Received: (qmail 2720 invoked by uid 76); 23 Feb 2007 14:05:05 -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 2715 invoked from network); 23 Feb 2007 14:05:04 -0000 Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <5422d5e60702221951h1abb7e60l77717192900a63a8@mail.gmail.com> Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1378 Archived-At: On Thu, Feb 22, 2007 at 10:51:50PM -0500, Daniel Clark wrote: > I made a simple test case that should make this bug (or my error in > using the software) easy to reproduce. I'm attaching it since it is so > tiny; it is also available from > http://opensysadmin.com/bugs/runit/test1-service.tar.bz2 > > Below is a transcript of using it to demonstrate the problem: > > root@cmlab:/tmp# tar xfj test1-service.tar.bz2 > root@cmlab:/tmp# cd test1-service/ > root@cmlab:/tmp/test1-service# ./runsvdir-here > ^C > root@cmlab:/tmp/test1-service# ps auxw | grep [s]v > root 19882 0.0 0.0 2516 348 ? Ss 22:28 0:00 runsv > test1-service > root 19883 0.0 0.0 2656 368 ? S 22:28 0:00 > /usr/local/bin/svlogd -tt ./logs > root 19884 0.0 0.0 10060 1408 ? S 22:28 0:00 > /bin/sh ./test1-sv.sh > root@cmlab:/tmp/test1-service# sv exit > /tmp/test1-service/var-service/test1-service > root@cmlab:/tmp/test1-service# sleep 7 > root@cmlab:/tmp/test1-service# ps auxw | grep [s]v > root 19882 0.0 0.0 2516 348 ? Ss 22:28 0:00 runsv > test1-service > root 19883 0.0 0.0 2656 368 ? S 22:28 0:00 > /usr/local/bin/svlogd -tt ./logs > root@cmlab:/tmp/test1-service# rm var-service/test1-service > root@cmlab:/tmp/test1-service# sleep 7 > root@cmlab:/tmp/test1-service# ps auxw | grep [s]v > root 19882 0.0 0.0 2516 348 ? Ss 22:28 0:00 runsv > test1-service > root 19883 0.0 0.0 2656 368 ? S 22:28 0:00 > /usr/local/bin/svlogd -tt ./logs > > (I would think runsv and svlogd should not be showing up here, because > runsvdir is no longer running, sv exit has been called, and the run > director has been removed, with >5 second pauses between the removal > and the ps) When asked to exit, the runsv supervisor makes sure that all logs are written to the log service before terminating; it first sends TERM to the main service, then waits for it to terminate, and finally waits for the log service to terminate, before runsv exits itself. In the case of your example service, the main run script execs into a shell script that starts a 'sleep' subprocess. Now when runsv is told to exit, it sends the service (the ./test1-sv.sh shell script) a TERM signal, the shell script terminates (fine), but is leaving behind the 'sleep' subprocess. The log service's run script execs into a svlogd process, svlogd will terminate as soon as it sees end-of-file on the pipe connected to its standard input. Because there's still the 'sleep' subprocess running with its output connected to the pipe, and so to svlogd's standard input, svlogd will wait; it might well be that there's still data available on the pipe to be written to the logs. Once the 'sleep' subprocess exits, runsv should exit too. HTH, Gerrit.