General note on rc scripts and daemonizing
ed at 80386.nl
Sat Jul 17 10:56:59 UTC 2010
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
I've seen various cases in the past where people write rc scripts that
do the following:
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)? ]
Ed Schouten <ed at 80386.nl>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20100717/350623f8/attachment.pgp
More information about the freebsd-ports