Michael Glaesemann wrote:
When you say "daemon" here, are you referring to the qpsmptd process or
the runit process (or something else)? My understanding is runit process
is the one that needs to be restarted, which I can do by
unloading/loading the appropriate launchd plist.
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.
Would that explain why it was disconnecting immediately after accepting
the telnet connection? And just to confirm, this would be a bad thing,
right?
Correct on both counts. I realized after I sent my last e-mail that the
appropriate test is simpler:
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).
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.
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.
Also, did you choose fgrep qpstmpd to look for a process named
qpsmtpd? I'm wondering if it's not showing up because its parent
process is perl? (Though, similarly, I don't get any output from ps
other than the fgrep perl process) Looking at top, I do see there is
a perl process owed by www with rapidly changing pids (or rather, a
rapid sequence of perl processes owed by www).
Yes, that is exactly the behavior that I was looking for. The '-f'
would normally show enough details that grep'ing for qpsmtpd would show
the correct instance (as opposed to any other daemonized Perl script you
might be running). Under OS/X, you might use BSD semantics and add one
or more 'w' characters to the ps commandline for similar information.
Normally I wouldn't reuse a user like this. I'm using qpsmtpd in
conjunction with Bricolage[1] to automate some Bricolage tasks. For ease
of permissions handling, I have qpsmtpd running as the same user as
Bricolage. This machine is dedicated to the Bricolage server: it's only
handling smtp requests from the Bricolage server, rather than in front
of a mail system.
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).
John
