General note on rc scripts and daemonizing
in [Ports]
|
From: Ed Schouten on 17 Jul 2010 06:56 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)? ] -- Ed Schouten <ed(a)80386.nl> WWW: http://80386.nl/
From: jhell on 17 Jul 2010 18:43 On Sat, 17 Jul 2010 06:56, Ed Schouten wrote: In Message-Id: <20100717105658.GV1742(a)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 _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: jhell on 18 Jul 2010 00:02 On Sat, 17 Jul 2010 18:43, jhell wrote: In Message-Id: <alpine.BSF.2.00.1007171823210.26551(a)pragry.qngnvk.ybpny> > > On Sat, 17 Jul 2010 06:56, Ed Schouten wrote: > In Message-Id: <20100717105658.GV1742(a)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, > > 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 _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Anonymous on 18 Jul 2010 00:24 jhell <jhell(a)DataIX.net> writes: > Also another use with the case above. Running top(1) instead of su(1) > you should see the same symptoms. > Use `-f' option in daemon(8). Otherwise it'd still spam to tty. $ daemon top $ procstat -f $(pgrep top) PID COMM FD T V FLAGS REF OFFSET PRO NAME 36719 top cwd v d -------- - - - /home/blah 36719 top root v d -------- - - - / 36719 top 0 v c rw------ 9 686053 - /dev/pts/3 36719 top 1 v c rw------ 9 686053 - /dev/pts/3 36719 top 2 v c rw------ 9 686053 - /dev/pts/3 36719 top 3 v c r------- 1 0 - /dev/null 36719 top 4 v c r------- 1 0 - /dev/null > I should probably also state that using the -f flag to ssh(1) without > daemon(1) does not exhibit any of these symptoms. _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
From: Greg Larkin on 20 Jul 2010 18:01 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Schouten wrote: > 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 all, Ed alerted me to this problem in the mail/nullmailer port some months back, and I fixed it with his assistance. A user recently opened a PR on another port I maintain (devel/viewvc), and I noticed that it had the same problem with its standalone server. This was a little harder to fix, since viewvc is a Python script. Anyway, here are some examples for daemonizing processes that don't already have support for doing it themselves: Daemonizing an executable without internal daemon support: http://www.freebsd.org/cgi/cvsweb.cgi/ports/mail/nullmailer/files/nullmailer.in?rev=1.3;content-type=text%2Fplain Daemonizing a Python script: http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/viewvc/files/viewvc.in?rev=1.4;content-type=text%2Fplain I would love to see direct support for these use cases in /etc/rc.subr, and am interested in working with someone to add it. - -Greg - -- Greg Larkin http://www.FreeBSD.org/ - The Power To Serve http://www.sourcehosting.net/ - Ready. Set. Code. http://twitter.com/sourcehosting/ - Follow me, follow you -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD4DBQFMRhyl0sRouByUApARAtJGAJoCt2be6rCer1Ws2wozsHrOS07W/wCYj/Vf Wg2eRfLqb/dHa/VjnqxlPA== =hbwR -----END PGP SIGNATURE----- _______________________________________________ freebsd-ports(a)freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscribe(a)freebsd.org"
|
Next
|
Last
Pages: 1 2 3 Prev: lang/perl5.12 segfault (amd64 - 8-STABLE) Next: Port installing localized manual pages. |