From owner-freebsd-rc@FreeBSD.ORG Sun Jul 18 04:02:19 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 EA30E1065676; Sun, 18 Jul 2010 04:02:18 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9B42E8FC0C; Sun, 18 Jul 2010 04:02:18 +0000 (UTC) Received: by iwn35 with SMTP id 35so4383147iwn.13 for ; Sat, 17 Jul 2010 21:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:date:from:to:cc :subject:in-reply-to:message-id:references:user-agent :x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; bh=z1cSO9xmHJL5KiQF2E5CV5Wve2m/C2Fbc2jHvk1ghsM=; b=Q2rneEIxzR45381G+35yWXhvVD9MgRN6vAGWfCx0jkyFttjtnVB1MCMmgb1nPEiCld 2QqQncVtzhlr3/95BiZpZGVQPF6HBuEQgyHndjtO3rw89x72d7cFLWslCZRLh0wTGPG2 0AeRp4/PmNuCxNFsLjMjndfqHjVTj0uLc1UmI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:x-openpgp-key-id:x-openpgp-key-fingerprint:mime-version :content-type; b=k2Ic9F32LkMNefmEqlXKkbu7zLO+97twNgbjbW6Ku7yjsppSYgz/ZXeq+Q+5n66sjo ZGx/T2VNHHdfgpp9S8w2wmrZs1QSrvAE9+BYtdKDxyrz5E/qrMa30PE9M/CzFOdgCst9 bhUD+1l3x3UQI8XfIzkIpOP/LE1g7zkMdpLZA= Received: by 10.231.32.200 with SMTP id e8mr3178205ibd.66.1279425737945; Sat, 17 Jul 2010 21:02:17 -0700 (PDT) Received: from centel.dataix.local ([99.181.132.254]) by mx.google.com with ESMTPS id e8sm17955140ibb.20.2010.07.17.21.02.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 17 Jul 2010 21:02:17 -0700 (PDT) Sender: "J. Hellenthal" Date: Sun, 18 Jul 2010 00:02:09 -0400 From: jhell To: Ed Schouten In-Reply-To: Message-ID: References: <20100717105658.GV1742@hoeg.nl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-Id: 0x89D8547E X-OpenPGP-Key-Fingerprint: 85EF E26B 07BB 3777 76BE B12A 9057 8789 89D8 547E MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 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: Sun, 18 Jul 2010 04:02:19 -0000 On Sat, 17 Jul 2010 18:43, jhell wrote: In Message-Id: > > On Sat, 17 Jul 2010 06:56, Ed Schouten wrote: > In Message-Id: <20100717105658.GV1742@hoeg.nl> > >> 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 Ed, > > Very nice note as well a very good practice. I have noticed this for > a while but never looked into it more so I could not really put a name to it. > Thanks. > > > Off topic of ports: > > While this subject is hot, I have been doing the following on an > updated system, current version of xterm on two up-to-date stable/8 machines. > I am having trouble narrowing down the cause of the controlling pseudo > terminal freezing until ^C is hit after using daemon(1) to spawn ssh in the > background to start a remote xterm. > > > # Open a pseudo terminal [pts/13] > xterm (the culprit) > > # Mix up the terminal a little so its not so fresh. [pts/13] > ls -l > > # Use daemon to start a remote xterm through ssh. [pts/13] > daemon ssh -M remotehost xterm > > At this stage the remote x11 forwarded xterm opens and works properly "set > this terminal aside, its not the problem". > > # On the originating pseudo terminal [pts/13] > su - > Password: ********** > host# _ > > After that you should have to hit ^C to proceed to the next bang line or > enter anything for that matter. > > Any clue at what might be going on or any more information that I could > provide to help deduce this ?. > > > Regards, > > Also another use with the case above. Running top(1) instead of su(1) you should see the same symptoms. I should probably also state that using the -f flag to ssh(1) without daemon(1) does not exhibit any of these symptoms. Regards, -- jhell,v