From owner-freebsd-rc@FreeBSD.ORG Sat Jul 17 10:56:59 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 B23011065676; Sat, 17 Jul 2010 10:56:59 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from mx0.hoeg.nl (unknown [IPv6:2a01:4f8:101:5343::aa]) by mx1.freebsd.org (Postfix) with ESMTP id 35EED8FC0C; Sat, 17 Jul 2010 10:56:59 +0000 (UTC) Received: by mx0.hoeg.nl (Postfix, from userid 1000) id 2F0E82A28CE6; Sat, 17 Jul 2010 12:56:58 +0200 (CEST) Date: Sat, 17 Jul 2010 12:56:58 +0200 From: Ed Schouten To: ports@FreeBSD.org Message-ID: <20100717105658.GV1742@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m+Z5/NEwv9nnRDo7" Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: rc@FreeBSD.org Subject: General note on rc scripts and daemonizing X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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: Sat, 17 Jul 2010 10:56:59 -0000 --m+Z5/NEwv9nnRDo7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=3D"/usr/local/bin/dog" command_args=3D"--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 =3D 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)? ] --=20 Ed Schouten WWW: http://80386.nl/ --m+Z5/NEwv9nnRDo7 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (FreeBSD) iEYEARECAAYFAkxBjHoACgkQ52SDGA2eCwW9eACePfuAF5ru1p/VB0hOdtBhCXzD GooAnjOnQln6tR2XRY93kWnlG0OEL6HA =uzUz -----END PGP SIGNATURE----- --m+Z5/NEwv9nnRDo7--