On Jun 6, 2006, at 22:34 , John Peacock wrote:
The *service* daemon runs forever and it starts the *qpsmtpd*
daemon, which runs until it exits (at which point the service
daemon restarts it). In this case, I meant qpsmtpd.
Thanks for the clarification.
I realized after I sent my last e-mail that the appropriate test is
simpler:
Thanks for taking the time to provide this alternate method and
explaining it so well. I feel like I'm actually beginning to
understand what's going on :) (though see immediately below :/)
1) remove the link from the qpsmtpd directory to the service
directory (to make sure that the service daemon doesn't try and
start it).
I don't see any sort of link from the qpsmptd directory to the
service directory. Perhaps this is the key to the whole problem. I
created the /var/service/qpsmptd/ directory and the /var/service/
qpsmptd/run script manually. A supervise directory was created in /
var/service/qpsmtpd/ automatically. I believe this happened after
loading the launchd runit plist the first time, though I
unfortunately didn't note exactly when I first noticed the supervise
directory. Perhaps this missing link is causing the problems?
In lieu of removing the link, I unloaded the runit plist which
prevents runit from running at all, which should have the effect of
preventing the service daemon from doing anything at all, much less
restarting qpsmptd.
2) execute the run file in a shell, e.g.
$ sudo ./run
3) connect to qpsmtpd from another shell and confirm that it
accepts mail.
4) make sure that qpsmtpd's log entries appear in the 'run' window
(this is how you can make sure that these will eventually be logged
correctly).
5) qpsmtpd should continue running until you type ^C (control-C) in
the shell.
I was able to execute the ./run script in the shell, connect to
qpstmpd using telnet in another shell (and making sure it worked as
expected with Bricolage via smtp), and verified that the the run
shell displayed evidence of the connections, so that much seems to be
working okay. ^C also worked as expected, verified using
$ ps -ewwa | fgrep qpsmtpd
11604 p1 S+ 0:01.47 /usr/bin/perl -w /usr/local/qpsmtpd/qpsmtpd-
forkserver --user www --port 25
11705 p2 S+ 0:00.00 fgrep qpsmtpd TERM=xterm-color SHELL=/bin/
bash SSH_CLIENT=172.16.1.101 65336 22 SSH_TTY=/dev/ttyp2 USER=admin1
MAIL=/var/mail/admin1 PATH=/usr/local/bin:/usr/local/sbin:/usr/local/
pgsql/bin:/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/
sbin PWD=/Users/admin1 SHLVL=1 HOME=/Users/admin1 LOGNAME=admin1
SSH_CONNECTION=172.16.1.101 65336 172.16.2.99 22 _=/usr/bin/fgrep
OLDPWD=/var/service
Thanks for the pointer on using -ww. I included the -a option
displays other users' processes.
6) you can now softlink the qpsmtpd directory into the service
directory and it should again accept mail and log entries should
show up in the log file.
Rather than creating /var/service/qpsmptd and /var/service/qpsmtpd/
run, should I instead move the /var/service/qpsmtpd/run into /usr/
local/qpsmptd/ (my qpsmptd installation directory), and symlink /var/
service/qpstmpd to /usr/local/qpsmptd? Is this the usual way to do this?
Nonetheless, Bricolage will be communicating with the qpsmtpd
service via an ip port (doesn't have to be 25), so there is no
reason that qpsmtpd needs to be the same user. There are no
permissions issues involved as qpsmtpd does not have any way to
read files off disk (that it didn't create).
I didn't explain myself as clearly as I'd have liked to. (Partly a
consequence of operating at the bleeding edge of my experience -- but
that's where learning occurs, right?) Answered downthread.
Michael Glaesemann
grzm seespotcode net
