From owner-freebsd-ports@FreeBSD.ORG Tue Jul 20 22:38:47 2010 Return-Path: Delivered-To: ports@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4EB3106567A for ; Tue, 20 Jul 2010 22:38:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 0A2F88FC1A for ; Tue, 20 Jul 2010 22:38:46 +0000 (UTC) Received: (qmail 2354 invoked by uid 399); 20 Jul 2010 22:38:45 -0000 Received: from localhost (HELO laptop.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 20 Jul 2010 22:38:45 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Date: Tue, 20 Jul 2010 15:38:44 -0700 (PDT) From: Doug Barton To: Greg Larkin In-Reply-To: <4C461CA5.2040307@FreeBSD.org> Message-ID: References: <20100717105658.GV1742@hoeg.nl> <4C461CA5.2040307@FreeBSD.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-message-flag: Outlook -- Not just for spreading viruses anymore! OpenPGP: id=1A1ABC84 Organization: http://SupersetSolutions.com/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: ports@FreeBSD.org, Ed Schouten , rc@FreeBSD.org Subject: Re: General note on rc scripts and daemonizing X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 22:38:47 -0000 On Tue, 20 Jul 2010, Greg Larkin wrote: > 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. Unfortunately not all port maintainers follow this list, so you're not off the hook yet. :) I did a quick and dirty grep for this problem and it looks like it affects about 76 ports, so not an overwhelming number, but not a quick afternoon's work either. >> 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. :-) Thanks for your excellent analysis of this problem, it's very useful information. >> 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)? ] In theory, yes. Currently daemon(8) is located in /usr/sbin which could be problematic for people doing diskless, but in practice I don't know of any ports rc.d scripts that start so early that this would be a problem. If it turns out that it is, we can always move it to /sbin. > 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. Your first example looks right, I don't know enough about python to comment on the second. There is also http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/90163 which has some insight into this. I previously closed that PR, but now it may be time to revisit this problem. I heartily encourage you to go forward if you're interested in patching rc.subr to take care of this. However, there will have to be a ramp-up period since even if you fix it today, you have about 3 years before you can guarantee that users on all supported versions of FreeBSD have the code in rc.subr (which is one of the unstated reasons that I closed the PR mentioned above). Here is my perspective on the project: 1. Document the issue in http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/rc-scripts.html and give examples of how to do it properly. 2. Contact authors of existing ports that have this issue, and point them to the documentation. Offer help to fix it. 3. Take a page from pgolluci's book and file PRs with fixes for those who don't respond in a timely manner, then use the "maintainer timeout" facility to finish the fixes. 4. After 1., but perhaps in parallel with 2. and 3.; develop a patch for rc.subr to handle this, perhaps starting with the simple cases. The patch should include a signaling mechanism so that a port rc.d script can do something equivalent to: if [ $rc_subr_with_daemon_fix ]; then do it the easy way else do it the hard way fi 5. Once there is a new mechanism, repeat the steps in 1-3. :) 6. In 3-4 years, remove the crutches and mandate use of the new mechanism. One could also argue that documentation and education are the right answers, and that patching rc.subr is not necessary. Personally I'm sympathetic to that line of reasoning, but I'd never want to discourage someone from improving rc.subr. If you, or anyone are interested in pursuing any part of this then I'm happy to help review patches, make suggestions, etc. but I am not going to be able to own the project, I don't have the time. I would suggest that starting a new thread on -rc would be the right way to move forward. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso