General note on rc scripts and daemonizing

[Greg Larkin]

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