General note on rc scripts and daemonizing

[Doug Barton]

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 at . 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