On Sat, 28 Mar 2015 12:31:04 +0000 Nuno Magalhães <[email protected]> wrote:
> On Sat, Mar 28, 2015 at 12:15 PM, poitr pogo <[email protected]> > 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
