Well, I believe we have some good news. Thank you again for your
help, Jake.
With the latest changes (detailed below), the restart of /send wasn't
throwing the errors it was before. So I removed the recordio from the
run file for send, ran Jake's qfixq script again (it found several
errors in the queue, quite possibly caused while all those other
errors were being thrown), and restarted qmailtoaster - the whole suite.
The queue is down to half its size and dropping. It appears to have
been - I'm guessing, but it seems accurate - the oversized
maildrop.log. I'll need to edit the logrotate.conf files so that it
rotates.
If I might make a suggestion? Since we use maildrop in toaster,
perhaps we should make sure one of our appropriate SRPMs sets up
rotation for maildrop.log ?
Anyway. Thank you very, very much, Jake, for all of your help. And
everyone else. This is a huge weight of stress off my shoulders.
Roxanne
On Oct 6, 2007, at 9:07 PM, Roxanne Sandesara wrote:
Yeah. It was huge. Sorry about that. But I really wasn't sure what
to keep and what to clip. :(
My /var/log/maildrop/maildrop.log was ... gigantinormous. I don't
feel like doing byte math, but I'm pretty sure it was at least
close to 2gb. So, I moved that to .log.old-<date> and created a new
file of the same original name, same group, user and permissions,
in the original location. On the off chance that was at all
contributing.
Now. It's possible I've done something stupid. That's always
possible. But there was no localconcurrency file in /var/qmail/
control in my installation. I created one, just in case, and put 30
in it.
I did have a concurrencyremote file. So I also created a
concurrencylocal, in case that was a misnomer.
I've restarted just the /send service, waiting to see if it will
process now.
I've also started DLing a copy of the ISO for QMT-ISO. If this
doesn't work, I'm going to go ahead and wipe and rebuild. I really
do need to get this mailserver back up and running.
I'll let you all know what happens. And thanks again, Jake, for all
of your help, regardless of how this turns out. I appreciate it.
On Oct 6, 2007, at 8:37 PM, Jake Vickers wrote:
Roxanne Sandesara wrote:
OK. I put recordio at the start of the command line within the
run file within /var/qmail/supervise/send and started up just the
send service. What follows is the log /var/log/qmail/send/current:
[EMAIL PROTECTED] ~]# cat /var/log/qmail/send/current
@400000004707b77f074e75e4 status: local 5/10 remote 0/60
@400000004707b77f07d19c1c delivery 7976: deferral:
maildrop:_signal_0x19/user_does_not_exist,_but_will_deliver_to_/
home/vpopmail/domains/<primary_domain_name>/blackhole//
Man - that was a big email.
It looks like it's making deliveries at first, but gets overloaded
after a while. I'd suggest increasing your local concurrency (/var/
qmail/control/localconcurrency) to 30 or 50 (default is 10). I'm
also worried by this maildrop error - last time I saw that it was
because someone's maildrop.log was 2G. Check that as well.
---------------------------------------------------------------------
QmailToaster hosted by: VR Hosted <http://www.vr.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
