From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/322 Path: main.gmane.org!not-for-mail From: Alejandro Mery Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: runit-1.0.0 release Date: Mon, 16 Feb 2004 19:04:40 -0300 Message-ID: <40313E78.30705@geeks.cl> References: <20040210153548.16191.qmail@56dafcc887170f.315fe32.mid.smarden.org> <20040211192355.17755561@rad1.109bean.org.uk> <20040211204212.12241.qmail@771d3fc1654724.315fe32.mid.smarden.org> <20040212174120.26bcb697@rad1.109bean.org.uk> <20040212204520.26049.qmail@c032e53e4f6f05.315fe32.mid.smarden.org> <20040212211510.GA11016@socomep> <20040214122150.5818.qmail@8f3ccfd96ce13e.315fe32.mid.smarden.org> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1076969107 17609 80.91.224.253 (16 Feb 2004 22:05:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2004 22:05:07 +0000 (UTC) Cc: supervision@list.skarnet.org Original-X-From: supervision-return-560-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Feb 16 23:04:43 2004 Return-path: Original-Received: from antah.skarnet.org ([212.43.221.114]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1Asqr5-0007hx-00 for ; Mon, 16 Feb 2004 23:04:43 +0100 Original-Received: (qmail 23653 invoked by uid 76); 16 Feb 2004 22:04:58 -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 23647 invoked from network); 16 Feb 2004 22:04:57 -0000 User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en Original-To: Gerrit Pape In-Reply-To: <20040214122150.5818.qmail@8f3ccfd96ce13e.315fe32.mid.smarden.org> Xref: main.gmane.org gmane.comp.sysutils.supervision.general:322 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:322 Gerrit Pape wrote: >On Thu, Feb 12, 2004 at 06:15:10PM -0300, Alejandro Mery wrote: > > >>i'm using runit on a ROCKLinux, (something betwen LFS and gentoo, but >>it's crossplatform and your final product is an installable ISO >>instead of a running system), here nothing else than runit itself stop >>me to drop 100% sysvinit. >> >>i'm just waiting for the last basic tools of sysvinit, for some >> >> > >What exactly are they? I think runit is rather complete, you don't >necessarily need pidof or local login accounting. Also sulogin is not >mandatory, you could also use some getty, e.g. fgetty. > > well only reboot and halt/poweroff are a must have. because they need to run inside stages 3 to actually do the thing. killall is at psmisc so no problem with it. shutdown, last, lastb, mesg and wall are usefull administrative tools bin/pidof is not need needed in pure supervised enviroment but... (see fghack) >>missing tools from daemontools like fghack (damn nullmailer) and to >> >> > >Which ones beside fghack? I personally don't use fghack, as it doesn't >allow the service to be controlled through signals like other services. >Instead of using fghack, the daemon really should be adapted, or as a >workaround started from stage 1. > > fghack.... i haven't get an answer from nullmailer people and no time yet to trace it. i agree that those daemons has to be addapted but sometimes you don't have access to the source of the 'buggy' program or you just don't know how to fix it (e.g. me and perl based daemons) i don't know how fghack works but can i use it to warranty the restart of the daemon if it crashes? can i use it to kill the daemon when needed? moving them to stage 1 can follow a bad migration due to dependencies. a workaround i did use was to loop forever after running it and pidof/kill on ./finish, but pidof is not part of runit, so i would need to 'fake' it using ps/grep/cut what's not optimal. (browsing /proc is a worse idea for a ./finish) >>finily trace why runit-3 waits for ever the active ssh sessions to >> >> > >This is a feature. Most probably you run sshd with a log service. >runsv, when asked to exit, makes sure that all logs get written by the >log service it additionally monitors for this service. This is one >reason why the service directory and the service/log directory are >monitored by a single supervisor with runit. > >If runsv is told to take the sshd service down, it sends a term signal >to the main sshd process. The main sshd process then exits, but it has >spawned children for active ssh connections, and leaves them alone. If >you run the sshd service with a appendant log service, the children have >inherited filedescriptor 1, which is connected to the log service >through a pipe. The sshd/log service waits for data as long as there >still are processes possibly writing data; you can set a timeout through >svwaitdown though. > > i have... echo 'Waiting for services to stop...' svwaitdown -xk -t350 /service/* and i got a *very* unconfortable state when one box had to reboot but it passed the whole weekend in stage 3 just because one damn user didn't close his ssh client. there is a change to fix svwaitdown to signal grandsons after the timeout, give them $t to suicide and if they still alive annihilate their whole family and continue stage 3? .oO( that can be misunderstood out of context ) >Without a sshd/log service, the behavior should change, but you lose the >guarantee for your log. > > as i see it i completely lost the log >Regards, Gerrit. > > Regards, Alejandro Mery