[EMAIL PROTECTED] wrote:
> Clearly, to me, that I don't fully understand tcpserver and the
> svc commands.
OK, off topic discussion follows. Anyone who understands Dan Bernstein's
software, please look away now, because I'll probably make very outragous
simplifications in the service of clarity... ;-)
1) Installing the daemontools does basically two things:
a) creates a /service directory;
b) starts a long-running process called svscan[1] which monitors that directory
and trys to execute any PROJECT/run file it finds and keeps it running[2].
2) tcpserver is a generic TCP server (hence it's name) which executes a child
program for every connection on the IP/port that tcpserver is monitoring.
tcpserver allows any application to act as a TCP server simply by reading STDIN
(for input) and writing STDOUT (for output) without having to do anything about
sockets, etc. tcpserver also has the ability to restrict connections by IP
address, limit the number of connections, etc.
What this has to do with qpsmtpd is that the original qpsmtpd typically used
tcpserver as the master server process that would spawn additional instances
of qpsmtpd for each connection that was made. This is slow and inefficient
(less so with resident Perl instances like pperl), and has been subsumed in
later invocations with qpsmtpd-forkserver (production 0.3x) and a pollserver
implementation (devel in trunk) which will scale to thousands if not more
simultaneous connections.
> I was under the impression that if you set things up with
> the service directory and such, that it would invoke a new qpsmtpd (or in
> this case, qpsmtpd-forkserver) for each connection. Obviously, we don't
> want the latter.
Right in one. qpsmtpd-forkserver, on the other hand, *is* the master process,
so it will handle forking off a new instance for each connection. However,
qpsmtpd-forkserver is still (typically) managed by daemontools, and hence can be
managed by the same tools.
> But to answer your question - yes, my current init.d script does
> use the svc command for just about everything.
I'm guessing you come to daemontools from a history of one of the qmail-toaster
installations, right? The init.d scripts are completely useless artifacts for
people who don't feel comfortable using the daemontools paradigm (IMNSHO).
There is no reason to use an init.d script to start and stop svscan managed
applications during boot or shutdown (svscan does this just fine). And typing
`svc -d /service/PACKAGE` is frequently shorter than the init.d invocation
anyways (see #2 below).
John
[1] - technically init starts svscanboot, which starts svscan and readproctitle
(which captures any svscan managed app's proctitle changes, which is a very nice
way for applications to emit error messages which don't write to a log file,
which is a great idea for a log program that can't currently write to a file,
don't you know!).
[2] - svscan will restart any application whose run file exits, unless it finds
a file called 'down' in which case it will note that but not start the run file.
This is what `svc -d` creates and `svc -u` deletes. Try typing the following:
# svc -d /service/PACKAGE
# svstat /service/PACKAGE
and you'll see that svscan has noted that the service is normally up, but has
been down for X seconds. Pretty cool. Other popular svc commands are:
svc -t /service/PACKAGE - sends a SIG_TERM (usually restarts)
svc -a /service/PACKAGE - sends a SIG_ARLM (reload config?)
svc -h /service/PACKAGE - sends SIG_HUP (rerun queue?)
svc -x /service/PACKAGE - stops svscan from running in this directory
That last one bears some additional details. If you want to completely halt a
service from running and not let it start up the next time the machine is
rebooted (i.e. remove it from svscan for good), you typically do this:
# cd /service/PACKAGE
# rm /service/PACKAGE
# svc -dx . ./log
What that does is to:
A) change into the real directory where the application lives (remember that all
"directories" in /service are just softlinks to the real application);
B) deletes the softlink itself (not the directory);
C) sends a SIG_TERM to the applciaiton (halting it) and stops svscan running in
this directory and the log directory (since svscan is actually executed vs the
real directory not the softlink).
If you just do `svc -x` it will stop svscan from executing, but if you don't
remove the softlink first, svscan will restart in that directory in the next
five seconds.
