On Sat, 28 Mar 2015 12:31:04 +0000
Nuno Magalhães <nunomagalhaes@???> wrote:

> On Sat, Mar 28, 2015 at 12:15 PM, poitr pogo <lepoitr@???>
> wrote:
> > S6 even forces such a program must not handle daemon mode itself.
> >     That process must not "background itself": being run by a
> > supervision tree already makes it a "background" task.

>
> I don't know its innards, but i find it awkward that a program would
> force, thus prevent another from daemonizing. Can you explain?
>
> Cheers,
> Nuno

Yes. First, see http://en.wikipedia.org/wiki/Daemon_%28computing%29 for
the definition of "daemon". Here's a quote from the page:

=========================================================
In multitasking computer operating systems, a daemon (/ˈdiːmən/
or /ˈdeɪmən/)[1] is a computer program that runs as a background
process, rather than being under the direct control of an interactive
user.
=========================================================

It's a program running in the background, in no way attached to an
interactive terminal. There are many, many ways to achieve this,
including these common tricks:

myprogram &

nohup myprogram &

Double-fork


I haven't read all the daemontools code, but from ps axjf, it appears
to me that the daemontools svscan program runs an instance of the
daemontools supervise for each directory symlinked to /service, and each
of those supervise programs runs its directory's run script, probably
using popen to capture the run script's stdout.

Why capture stdout? Because, for each /service/whateverd directory, it
also runs supervise on /service/whateverd/log , and passes the stdout
to the log.

Because supervise runs its runscript *in the foreground*, it has access
to its stdout, and has access to its current PID. No more playing
"parse ps ax and guess" or doing detective work in /proc. In fact,
svstat /service/whateverd gives you whateverd's PID. Daemontools
wouldn't be able to do this stuff if supervise chose to run its service
in the background, relative to itself. With the daemontools method you
get much better control.

Now meanwhile, any "daemon" worth its salt gives you a way to run it in
the foreground:

* ntpd -d
* sshd -D
* smbd -F
* nmbd -F

So, in the daemontools run script for the program, you just run it with
the "don't detach" option.

The fact that the "daemon" is run, by supervise, in the foreground
gives you much more control, a lot more debugging options, and means if
you want to write your own "daemon", you don't need to worry about any
doublefork nonsense, nor write a file with its PID, and all that other
hassle.

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance