From owner-freebsd-rc@FreeBSD.ORG Tue Jul 20 22:34:37 2010 Return-Path: Delivered-To: rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09C461065672 for ; Tue, 20 Jul 2010 22:34:37 +0000 (UTC) (envelope-from glarkin@FreeBSD.org) Received: from mail1.sourcehosting.net (113901-app1.sourcehosting.net [72.32.213.11]) by mx1.freebsd.org (Postfix) with ESMTP id DB6318FC08 for ; Tue, 20 Jul 2010 22:34:36 +0000 (UTC) Received: from 68-189-245-235.dhcp.oxfr.ma.charter.com ([68.189.245.235] helo=cube.entropy.prv) by mail1.sourcehosting.net with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1ObKsC-000Bje-7U; Tue, 20 Jul 2010 18:01:17 -0400 Received: from [127.0.0.1] (fireball.entropy.prv [192.168.1.12]) by cube.entropy.prv (Postfix) with ESMTP id 102B842BBA55; Tue, 20 Jul 2010 18:01:12 -0400 (EDT) Message-ID: <4C461CA5.2040307@FreeBSD.org> Date: Tue, 20 Jul 2010 18:01:09 -0400 From: Greg Larkin Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ed Schouten References: <20100717105658.GV1742@hoeg.nl> In-Reply-To: <20100717105658.GV1742@hoeg.nl> X-Enigmail-Version: 0.96.0 OpenPGP: id=1C940290 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.3 (/) Cc: ports@FreeBSD.org, rc@FreeBSD.org Subject: Re: General note on rc scripts and daemonizing X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: glarkin@FreeBSD.org List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 22:34:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Schouten wrote: > Hello port maintainers, > > I think I'd better send an email about this to ports@, because I've seen > it in various places and it is getting a bit tiresome to mail all port > authors individually. > > I've seen various cases in the past where people write rc scripts that > do the following: > > command="/usr/local/bin/dog" > command_args="--bark > /dev/null 2>&1 &" > > So in this case `dog --bark' doesn't daemonize itself, so the & is > sufficient here, right? Well, it is not. :-) The point is that we simply > tell the kernel to redirect stdout/stderr and run it in the background. > It doesn't tell the kernel that the process should run in a separate > session (see getsid(2)/setsid(2)). > > This has various implications. The most important one I can think of, is > that the daemon can still do open("/dev/tty", ...) if it wants and spam > your TTY, even if the daemon is running as user `nobody'. This also > means that if you run the rc script from within a pseudo-terminal, it > can never actually destroy the pseudo-terminal for you, because maybe > the daemon is interested in using it. > > Below is the output of `pstat -t' on one of my systems, where I decided > to fire up MySQL: > > | LINE INQ CAN LIN LOW OUTQ USE LOW COL SESS PGID STATE > | ... > | pts/11 0 0 0 0 0 0 0 0 82711 0 G > > The kernel actually wants to clean up this pseudo-terminal (state = G), > but it is prevented from doing so. It will only clean it up by the time > MySQL is shut down. > > So how can this be solved? We already have a tool in base called > daemon(8). It is simply a wrapper around daemon(3) (which calls > setsid(2), which you can use to daemonize processes. So the next time > you write an rc script and need to daemonize something which cannot do > it by itself, please think of the kittens. ;-) > > [ CCing this to rc@. Maybe we should add some kind of built-in > functionality to call daemon(8)? ] > Hi all, Ed alerted me to this problem in the mail/nullmailer port some months back, and I fixed it with his assistance. A user recently opened a PR on another port I maintain (devel/viewvc), and I noticed that it had the same problem with its standalone server. This was a little harder to fix, since viewvc is a Python script. Anyway, here are some examples for daemonizing processes that don't already have support for doing it themselves: Daemonizing an executable without internal daemon support: http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/nullmailer/files/nullmailer.in?rev=1.3;content-type=text%2Fplain Daemonizing a Python script: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/viewvc/files/viewvc.in?rev=1.4;content-type=text%2Fplain I would love to see direct support for these use cases in /etc/rc.subr, and am interested in working with someone to add it. - -Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD4DBQFMRhyl0sRouByUApARAtJGAJoCt2be6rCer1Ws2wozsHrOS07W/wCYj/Vf Wg2eRfLqb/dHa/VjnqxlPA== =hbwR -----END PGP SIGNATURE-----