General note on rc scripts and daemonizing

[jhell]

On Sat, 17 Jul 2010 06:56, Ed Schouten wrote:
In Message-Id: <20100717105658.GV1742 at hoeg.nl>

> 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 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,

-- 

  jhell,v