Re: [qmailtoaster] Queued into surrender

[Roxanne Sandesara]

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- 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

@40004707b77f074e75e4 status: local 5/10 remote 0/60

@40004707b77f07d19c1c delivery 7976: deferral:  
maildrop:_signal_0x19/user_does_not_exist,_but_will_deliver_to_/ 
home/vpopmail/domains//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 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] Queued into surrender

[Roxanne Sandesara]

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- 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

@40004707b77f074e75e4 status: local 5/10 remote 0/60

@40004707b77f07d19c1c delivery 7976: deferral:  
maildrop:_signal_0x19/user_does_not_exist,_but_will_deliver_to_/ 
home/vpopmail/domains//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 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] Queued into surrender

[Jake Vickers]

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

@40004707b77f074e75e4 status: local 5/10 remote 0/60

@40004707b77f07d19c1c delivery 7976: deferral: 
maildrop:_signal_0x19/user_does_not_exist,_but_will_deliver_to_/home/vpopmail/domains//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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Queued into surrender

[Jake Vickers]

Roxanne Sandesara wrote:
OK. I tried 'recordio svc -u /var/qmail/supervise/send', but that 
clearly doesn't work, as that is just a service script. All I get is 
an EOF and a hanging process. What program(s) should I call with 
recordio to try to get some meaningful information?


Obviously, I'd prefer to fix this, as it would also add to our 
knowledge base regarding what is happening and perhaps then what 
caused the situation. But are we reaching the point that I should just 
consider running that backup, wiping the box and rebuilding? 
Admittedly, it would take me the rest of today to do that. But I do 
need to figure this out and fix it.


You'll need to put the recordio command in the supervise file (called 
run) for qmail-send. Then it should just add extra output to the logs 
(massive amounts, depending on the load).
As far as reaching the point of wiping and starting over, that's a call 
you have to make. I don't know what all is run off your machine so I 
can't make a guess as to how critical it is. My machines would take me 
hours each to backup since I usually run something else on the machine 
as well - I'd move the backup to another server and change the MX record 
while I got the main one working in my situations. That may not work for 
you.
I'd also like to point out I do have the QMT-ISO (qmtiso.com) that will 
give you a Cent 4.5 and Toaster install in one fell swoop (okay, 3 
reboots total). I'm not a fan of Cent5 myself - it's rather bloated for 
my tastes.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Queued into surrender

[Roxanne Sandesara]

OK. I tried 'recordio svc -u /var/qmail/supervise/send', but that  
clearly doesn't work, as that is just a service script. All I get is  
an EOF and a hanging process. What program(s) should I call with  
recordio to try to get some meaningful information?


Obviously, I'd prefer to fix this, as it would also add to our  
knowledge base regarding what is happening and perhaps then what  
caused the situation. But are we reaching the point that I should  
just consider running that backup, wiping the box and rebuilding?  
Admittedly, it would take me the rest of today to do that. But I do  
need to figure this out and fix it.


On Oct 6, 2007, at 3:35 PM, Jake Vickers wrote:


Roxanne Sandesara wrote:
OK. I had queue-repair create a whole new queue, in case it was  
something niggling. However, in test mode it hadn't found anything  
wrong.


Having built a new queue, I have restarted qmail-send, and only  
send, to see if it will process through the queue. I assume I  
should let it sit for an hour or so, and then pull the latest  
messages out of qmlog send if it hasn't cleared the queue? Is  
there anywhere else I should be looking to find additional  
messages or information that would help troubleshoot this?


You may also try running recordio on it to see if it gives any more  
information while it's bombing out.
The options I'd given you already had fixed my problem in the past,  
so this is a new one for me as well.





-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] Queued into surrender

[Jake Vickers]

Roxanne Sandesara wrote:
OK. I had queue-repair create a whole new queue, in case it was 
something niggling. However, in test mode it hadn't found anything wrong.


Having built a new queue, I have restarted qmail-send, and only send, 
to see if it will process through the queue. I assume I should let it 
sit for an hour or so, and then pull the latest messages out of qmlog 
send if it hasn't cleared the queue? Is there anywhere else I should 
be looking to find additional messages or information that would help 
troubleshoot this?


You may also try running recordio on it to see if it gives any more 
information while it's bombing out.
The options I'd given you already had fixed my problem in the past, so 
this is a new one for me as well.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Queued into surrender

[Roxanne Sandesara]

OK. I had queue-repair create a whole new queue, in case it was  
something niggling. However, in test mode it hadn't found anything  
wrong.


Having built a new queue, I have restarted qmail-send, and only send,  
to see if it will process through the queue. I assume I should let it  
sit for an hour or so, and then pull the latest messages out of qmlog  
send if it hasn't cleared the queue? Is there anywhere else I should  
be looking to find additional messages or information that would help  
troubleshoot this?



On Oct 6, 2007, at 11:10 AM, Jake Vickers wrote:


Roxanne Sandesara wrote:
OK. Send is still not delivering, clearing up the queue at all.  
However, the queue is not re-corrupting itself. I'm not really  
sure /what/ to try next. Any suggestions? Should I just leave send  
running by itself for a while longer? (I tried forcing the issue  
with qmHandle -a to no avail).


Try the queue-repair tool as well - maybe a permission went awry.
http://pyropus.ca/software/queue-repair/




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [qmailtoaster] Queued into surrender

[Kevin Katz]

50% free on the disk is good - But, how about the partition holding the
queue? Do any of the partitions themselves show full?

Thank You
 Kevin Katz
   

-Original Message-
From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 05, 2007 6:00 PM
To: qmailtoaster-list@qmailtoaster.com
Subject: Re: [qmailtoaster] Queued into surrender

I've got nearly 50% free space on the disk.

On Oct 5, 2007, at 8:11 PM, Todd W wrote:

>
> From: "Roxanne Sandesara" <[EMAIL PROTECTED]>
>
>
>> /var/qmail/control/concurrencyremote = 60
>>
>> Any idea what 'unable to open todo' means? Or what I should do  
>> about it?
>>
>> /var/log/qmail/send current:
>> Script started on Fri 05 Oct 2007 04:52:25 PM EDT
>> ]0;[EMAIL PROTECTED]:~
[EMAIL PROTECTED] ~]# qmlog send
>> 10-05 16:52:15 warning: unable to open todo/3490361
>
> The only thing google found was http://securepoint.com/lists/html/ 
> Qmail/2007-04/msg00091.html
>
> A single reply to the op asked if the disk was full. There is no  
> reply.
>
> I imagine you saw it, too... but just out of curiosity is your disk  
> full?
>
> $ sudo df -h
>
> Regards,
>
> Todd W.
>
>
> -
> QmailToaster hosted by: VR Hosted 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: qmailtoaster-list- 
> [EMAIL PROTECTED]
>


-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
 QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] Queued into surrender

[Jake Vickers]

Roxanne Sandesara wrote:
OK. Send is still not delivering, clearing up the queue at all. 
However, the queue is not re-corrupting itself. I'm not really sure 
/what/ to try next. Any suggestions? Should I just leave send running 
by itself for a while longer? (I tried forcing the issue with qmHandle 
-a to no avail).


Try the queue-repair tool as well - maybe a permission went awry.
http://pyropus.ca/software/queue-repair/



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Queued into surrender

[Roxanne Sandesara]

OK. Send is still not delivering, clearing up the queue at all.  
However, the queue is not re-corrupting itself. I'm not really sure / 
what/ to try next. Any suggestions? Should I just leave send running  
by itself for a while longer? (I tried forcing the issue with  
qmHandle -a to no avail).


On Oct 6, 2007, at 10:02 AM, Roxanne Sandesara wrote:


Thank you.

I've run the script to repair the queue, and started up just send.  
I'm going to leave it to run for an hour or so, to see if it can  
manage to make the deliveries it needs to make. If not, I'll shut  
down send, check to see if the queue is corrupted again. If it is,  
I'll have to drop back and start with bringing the server down  
completely to scan the disks for corruption. I'm nowhere near to  
being out of space on the system:


[EMAIL PROTECTED] ~]# df
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
  86761840  41277944  41076600  51% /
/dev/sda1   101086 60813 35054  64% /boot
none   1037384 0   1037384   0% /dev/shm

I've got a backup of everything each week for the last two months,  
and I'll run another before I shut it down for disk scanning, just  
in case it can prove useful. Sadly, this may be the event that  
forces me to upgrade to CentOS 5, when rebuilding if that becomes  
necessary.


Thank you for the help, to Jake and to everyone else who tried.  
I'll keep everyone informed.



On Oct 6, 2007, at 9:28 AM, Jake Vickers wrote:


Roxanne Sandesara wrote:
Jake, how do I individually stop qmailtoaster services? Will  
qmailctl accept a second argument with the name of a service? Or  
do I need to 'kill' the processes? Is there a way to start up  
only selected services?




You can stop individual processes with the svc -d command:

svc -d /var/qmail/supervise/spamd /var/qmail/supervise/spamd/log


That stops the spamd and spamd-log daemons as an example. Look in / 
var/qmail/supervise for the names of the other daemons.
Once you stop a service, you can check to make sure it's stopped  
by 'qmailctl stat' or:



svstat /var/qmail/supervise/spamd









-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] Queued into surrender

[Roxanne Sandesara]

Thank you.

I've run the script to repair the queue, and started up just send.  
I'm going to leave it to run for an hour or so, to see if it can  
manage to make the deliveries it needs to make. If not, I'll shut  
down send, check to see if the queue is corrupted again. If it is,  
I'll have to drop back and start with bringing the server down  
completely to scan the disks for corruption. I'm nowhere near to  
being out of space on the system:


[EMAIL PROTECTED] ~]# df
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
  86761840  41277944  41076600  51% /
/dev/sda1   101086 60813 35054  64% /boot
none   1037384 0   1037384   0% /dev/shm

I've got a backup of everything each week for the last two months,  
and I'll run another before I shut it down for disk scanning, just in  
case it can prove useful. Sadly, this may be the event that forces me  
to upgrade to CentOS 5, when rebuilding if that becomes necessary.


Thank you for the help, to Jake and to everyone else who tried. I'll  
keep everyone informed.



On Oct 6, 2007, at 9:28 AM, Jake Vickers wrote:


Roxanne Sandesara wrote:
Jake, how do I individually stop qmailtoaster services? Will  
qmailctl accept a second argument with the name of a service? Or  
do I need to 'kill' the processes? Is there a way to start up only  
selected services?




You can stop individual processes with the svc -d command:

svc -d /var/qmail/supervise/spamd /var/qmail/supervise/spamd/log


That stops the spamd and spamd-log daemons as an example. Look in / 
var/qmail/supervise for the names of the other daemons.
Once you stop a service, you can check to make sure it's stopped by  
'qmailctl stat' or:



svstat /var/qmail/supervise/spamd







-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] Queued into surrender

[Jake Vickers]

Roxanne Sandesara wrote:
Jake, how do I individually stop qmailtoaster services? Will qmailctl 
accept a second argument with the name of a service? Or do I need to 
'kill' the processes? Is there a way to start up only selected services?




You can stop individual processes with the svc -d command:

svc -d /var/qmail/supervise/spamd /var/qmail/supervise/spamd/log


That stops the spamd and spamd-log daemons as an example. Look in 
/var/qmail/supervise for the names of the other daemons.
Once you stop a service, you can check to make sure it's stopped by 
'qmailctl stat' or:



svstat /var/qmail/supervise/spamd






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] Queued into surrender

[Roxanne Sandesara]

Jake, how do I individually stop qmailtoaster services? Will qmailctl  
accept a second argument with the name of a service? Or do I need to  
'kill' the processes? Is there a way to start up only selected services?




On Oct 6, 2007, at 8:59 AM, Jake Vickers wrote:


Roxanne Sandesara wrote:

/var/qmail/control/concurrencyremote = 60

Any idea what 'unable to open todo' means? Or what I should do  
about it?


/var/log/qmail/send current:
Script started on Fri 05 Oct 2007 04:52:25 PM EDT
]0;[EMAIL PROTECTED]:[EMAIL PROTECTED] ~]# qmlog send
10-05 16:52:15 warning: unable to open todo/3490361
10-05 16:52:15 warning: unable to open todo/3489933
10-05 16:52:15 warning: unable to open todo/3490361
10-05 16:52:15 warning: unable to open todo/3489933


I had a joe job attack a couple years back that ended up corrupting  
my queue:

http://qmail.jms1.net/scripts/qfixq.shtml




-
QmailToaster hosted by: VR Hosted 
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [qmailtoaster] Queued into surrender

[Jake Vickers]

Roxanne Sandesara wrote:

/var/qmail/control/concurrencyremote = 60

Any idea what 'unable to open todo' means? Or what I should do about it?

/var/log/qmail/send current:
Script started on Fri 05 Oct 2007 04:52:25 PM EDT
]0;[EMAIL PROTECTED]:[EMAIL PROTECTED] ~]# qmlog send
10-05 16:52:15 warning: unable to open todo/3490361
10-05 16:52:15 warning: unable to open todo/3489933
10-05 16:52:15 warning: unable to open todo/3490361
10-05 16:52:15 warning: unable to open todo/3489933


I had a joe job attack a couple years back that ended up corrupting my 
queue:

http://qmail.jms1.net/scripts/qfixq.shtml



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qmailtoaster] error 571-'sorry, sender address has invalid format (#5.7.1 - chkuser)'

[Jake Vickers]

Jim Shupert, Jr. wrote:

Friends,
 
I have a blckberry user who has the complaint of


5.1.0 - Unknown address error 571-'sorry, sender address has invalid 
format (#5.7.1 - chkuser)'


I find this in the wiki - ok , that sounds dead on


1.Is it generally agreed that "disabling the check for all incoming mail"
is a good solution? best solution? 
2. are there any - risks downsides? 
3. ( most importantly )if I wish to disabled the check for all incoming mail

:allow,BADMIMETYPE="",SENDER_NOCHECK="1",BADLOADERTYPE="M",CHKUSER_RCPTLIMIT="50",CHKUSER_WRONGRCPTLIMIT="10",QMAILQUEUE="/var/qmail/bin/simscan"
 exactly how do I do that?
4. do i have the option of editing my tcp.smtp 
and would I be correct in thing that it is as easy as

N.N.N.N:allow,RELAYCLIENT="",RBLSMTPD="",SENDER_NOCHECK="1"
where N.N.N.N is the blackberry mail server?
maybe 4 is my best solution... I so far- only have 1 complaint.
 


I wrote that wiki page, and then edited it later as a FYI.  I went 
through all the trouble of turning off the checks for all of 
Blackberry's MX entries and unfortunately Blackberry has a couple 
"ghost" mail servers that are not listed in DNS. I had a screaming 
client during the process, so I would fix it and the next day he would 
get the above message. I'd find the ghost MX server and add it telling 
him it was fixed, and it happened again the next day with a new ghost 
machine. After a couple of what looked like "foot in mouth" moments with 
my client I threw my hands up and turn off sender checking for the whole 
machine.
Those symbols are technically allowed by the RFC, and I could not really 
see how they could be used to exploit the system since they're not 
really translating to filenames or anything, so I do not see any reason 
to deny them.  I have been allowing them for a couple months now and 
have had no adverse effects from it.

My 2 cents.



smime.p7s
Description: S/MIME Cryptographic Signature