General note on rc scripts and daemonizing

jhell jhell at
Sun Jul 18 04:02:19 UTC 2010

On Sat, 17 Jul 2010 18:43, jhell wrote:
In Message-Id: <alpine.BSF.2.00.1007171823210.26551 at pragry.qngnvk.ybpny>

> On Sat, 17 Jul 2010 06:56, Ed Schouten wrote:
> In Message-Id: <20100717105658.GV1742 at>
>> 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:
>> | ...
>> |     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 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.




More information about the freebsd-ports mailing list