"Bryan J. Ischo" <[EMAIL PROTECTED]> wrote:
>I followed the instructions in the qmail HOWTO and got rid of sendmail
>entirely. But later in the day I discovered that emails simply were
>not getting delivered.
Didn't you test it after the install?
>qmail-smtpd was happily accepting them for
>delivery but where they went, who knows. We are using /var/mail
>files for receiving mail (for compatibility with our IMAP and POP
>servers). These files stopped being updated and I can find no
>traces of received mail anywhere in /var/qmail/queue.
Did you run qmail-qstat and qmail-qread? If your logging was working,
the qmail-send logs would be helpful.
>I was unable
>to send mail using the /bin/mail program on the mail host.
What does "unable to send mail" mean? Did the command return an error?
Did everything appear normal, except that the mail wasn't delivered
where you expected it? "I did some things and they didn't work" isn't
terribly helpful.
>So I
>tried the old sendmail.bak sendmail executable and, after making it
>suid again, it worked. So I removed the links from /usr/lib/sendmail
>and /usr/sbin/sendmail to /var/qmail/bin/sendmail, and replaced those
>links with links to the old sendmail.bak. Now users are receiving
>mail again. I find it very strange.
Yes, I find it strange that one would use Sendmail's sendmail in a
qmail installation, too. :-)
>My guess is that the fact that /var/qmail/bin/sendmail being
>group qmail and all of our mail files in /var/mail being group
>mail, and the fact that /var/qmail/bin/sendmail is not suid or
>anything, meant that it didn't have permissions to write mail
>to the mail files.
Sorry, that's not even close. The qmail sendmail just calls
qmail-inject, which places the message in qmail's queue, where's it's
picked up by qmail-send and passed to qmail-lspawn &|
qmail-rspawn. For a local delivery, qmail-lspawn calls qmail-local,
which, in your configuration, would invoke /bin/mail to do the final
delivery.
>Anyone know if there's any hope of recovering the mails which were
>lost at this time?
Hope? Sure. Whether they can or not depends upon what happened to
them. qmail is pretty careful not to toss messages, but /bin/mail
might not be.
>Silently lost mail files are the worst case
>scenario for a mail server and I am really afraid that that's what
>we have here.
If that happened, it wasn't qmail's fault, it was yours.
>The second problem we have is that qmail doesn't seem to log
>properly.
Correction: the second problem you have is that your qmail isn't
logging properly. qmail *does* log just fine for hundreds or thousands
of users. If yours isn't logging, it's because something is fubar'd
on your system.
>Qmail is started via:
>
>qmail-start '|preline -f /bin/mail "$USER"' splogger qmail
Where'd you get that? Have you looked at /var/qmail/boot/binm2?
>But where do the messages get logged?
splogger sends them to syslog. What syslog does with them is between
you and syslog. See "man syslogd" and "more /etc/syslog.conf".
>At no time have we ever
>received any log messages from qmail except for the following
>in /var/adm/messages:
>
>Sep 16 20:55:35 level qmail: 937529735.086563 alert: oh no! lost spawn
>connection! dying...
>
>Which occurred when I manually killed qmail when restarting it.
That's very strange. If that message was logged, you should have also
logged, at least, the startup message from qmail-send. If you do:
echo foo | /var/qmail/bin/splogger qmail
Does a message get logged?
Personally, I wouldn't spend much time trying to figure out syslog. I
use daemontools. See:
http://Web.InfoAve.Net/~dsill/lwq.html#start-qmail
-Dave
