Date: Sat, 17 Jul 2010 18:43:07 -0400 From: jhell <jhell@DataIX.net> To: Ed Schouten <ed@80386.nl> Cc: ports@freebsd.org, rc@freebsd.org Subject: Re: General note on rc scripts and daemonizing Message-ID: <alpine.BSF.2.00.1007171823210.26551@pragry.qngnvk.ybpny> In-Reply-To: <20100717105658.GV1742@hoeg.nl> References: <20100717105658.GV1742@hoeg.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 17 Jul 2010 06:56, Ed Schouten wrote: In Message-Id: <20100717105658.GV1742@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@. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1007171823210.26551>