On Sat, 17 Jul 2010 18:43, jhell wrote:
In Message-Id: <[email protected]>
On Sat, 17 Jul 2010 06:56, Ed Schouten wrote:
In Message-Id: <[email protected]>
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 r...@. 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.
Regards,
--
jhell,v
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
