Re: [qmailtoaster] Queued into surrender
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. 'ls -lh' will show you how big the files are in human readable numbers. And no, you didn't do anything stupid there. The file is not there by default, and uses a value of 10 until you create the file and put a different value in it. And it's no problem. We all try and help out where we can around here. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
Roxanne Sandesara wrote: 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. Guess I should have waited for the second message before replying. Erik found that maildrop.log issue a while back with someone else who was having similar problems. I think in the next release it's been earmarked to be added into logrotate. I'll be adding the option in the next QTP myself (I know, it's overdue, but I'll get some time to work on it next week while out of town). Glad to see it's working for you. Good luck! smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
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
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 http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
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 http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
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
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 http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
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 http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
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
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 http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
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 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/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. smime.p7s Description: S/MIME Cryptographic Signature
Re: [qmailtoaster] Queued into surrender
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 @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/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]
Re: [qmailtoaster] Queued into surrender
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 @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/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]
RE: [qmailtoaster] Queued into surrender
Hello, I just had this issue the other day. Have you looked at the tool qmHandle If you just type that in it will give you a list of options on how to deal with the queue. What do you have your queue lifetime set to? If you have Qmail toaster plus installed then you have qmHandle. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 1:58 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Queued into surrender My qmail-toaster seems to have hundreds, if not thousands of messages undelivered and sitting in the queue. This has reached the point that local messages, from users who are on the server to other users on the server, are not being delivered, even hours after they have been sent. I have followed the instructions on http:// wiki.qmailtoaster.com/index.php/Queuelifetime as well as attempting a reboot of the server. Nothing seems to clear out the queue, force the system to deliver or give up, and move on. Does anyone have any other suggestions. My users are frantic. They live by their email communication, and with that down, they are giving me no peace, and I currently have no useful solutions. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
I changed my queue lifetime to one hour (3600) qmHandle was useful for seeing what is in the queue. But I still can't get it to /process/ the queue. On Oct 5, 2007, at 2:00 PM, Kyle Quillen wrote: Hello, I just had this issue the other day. Have you looked at the tool qmHandle If you just type that in it will give you a list of options on how to deal with the queue. What do you have your queue lifetime set to? If you have Qmail toaster plus installed then you have qmHandle. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 1:58 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Queued into surrender My qmail-toaster seems to have hundreds, if not thousands of messages undelivered and sitting in the queue. This has reached the point that local messages, from users who are on the server to other users on the server, are not being delivered, even hours after they have been sent. I have followed the instructions on http:// wiki.qmailtoaster.com/index.php/Queuelifetime as well as attempting a reboot of the server. Nothing seems to clear out the queue, force the system to deliver or give up, and move on. Does anyone have any other suggestions. My users are frantic. They live by their email communication, and with that down, they are giving me no peace, and I currently have no useful solutions. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [qmailtoaster] Queued into surrender
Try this command qmHandle -M That will delete all of the email that was not able to be sent. See if that lessens the queue. The other day I just ended up deleting the entire queue. And all was well. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 2:33 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Queued into surrender I changed my queue lifetime to one hour (3600) qmHandle was useful for seeing what is in the queue. But I still can't get it to /process/ the queue. On Oct 5, 2007, at 2:00 PM, Kyle Quillen wrote: Hello, I just had this issue the other day. Have you looked at the tool qmHandle If you just type that in it will give you a list of options on how to deal with the queue. What do you have your queue lifetime set to? If you have Qmail toaster plus installed then you have qmHandle. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 1:58 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Queued into surrender My qmail-toaster seems to have hundreds, if not thousands of messages undelivered and sitting in the queue. This has reached the point that local messages, from users who are on the server to other users on the server, are not being delivered, even hours after they have been sent. I have followed the instructions on http:// wiki.qmailtoaster.com/index.php/Queuelifetime as well as attempting a reboot of the server. Nothing seems to clear out the queue, force the system to deliver or give up, and move on. Does anyone have any other suggestions. My users are frantic. They live by their email communication, and with that down, they are giving me no peace, and I currently have no useful solutions. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qmailtoaster] Queued into surrender
Wiping things out of the queue is not helping. It's not delivering anything to the users. However, mail is getting out. Is there something that could be preventing qmail from delivering messages to the users, thusly forcing the local queue sky-high? On Oct 5, 2007, at 3:54 PM, Kyle Quillen wrote: Is it possible to just purge the whole queue? I know it means lost email but I just bit the bullet and did it. Are these spam messages that your getting hit with an open relay? I had thousands of @yahoo.com.tw emails in mine. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 3:51 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Queued into surrender qmHandle -M deleted what appeared to be about 50 messages. There are still thousands of messages in the local queue. No mail is being delivered to the users. No mail is going out. This is really bad. On Oct 5, 2007, at 2:35 PM, Kyle Quillen wrote: Try this command qmHandle -M That will delete all of the email that was not able to be sent. See if that lessens the queue. The other day I just ended up deleting the entire queue. And all was well. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 2:33 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Queued into surrender I changed my queue lifetime to one hour (3600) qmHandle was useful for seeing what is in the queue. But I still can't get it to /process/ the queue. On Oct 5, 2007, at 2:00 PM, Kyle Quillen wrote: Hello, I just had this issue the other day. Have you looked at the tool qmHandle If you just type that in it will give you a list of options on how to deal with the queue. What do you have your queue lifetime set to? If you have Qmail toaster plus installed then you have qmHandle. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 1:58 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Queued into surrender My qmail-toaster seems to have hundreds, if not thousands of messages undelivered and sitting in the queue. This has reached the point that local messages, from users who are on the server to other users on the server, are not being delivered, even hours after they have been sent. I have followed the instructions on http:// wiki.qmailtoaster.com/index.php/Queuelifetime as well as attempting a reboot of the server. Nothing seems to clear out the queue, force the system to deliver or give up, and move on. Does anyone have any other suggestions. My users are frantic. They live by their email communication, and with that down, they are giving me no peace, and I currently have no useful solutions. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org
Re: [qmailtoaster] Queued into surrender
what can you see in your /var/log/qmai/send/current log? what is your /var/qmail/control/concurrencyremote value? On 10/5/07, Roxanne Sandesara [EMAIL PROTECTED] wrote: Wiping things out of the queue is not helping. It's not delivering anything to the users. However, mail is getting out. Is there something that could be preventing qmail from delivering messages to the users, thusly forcing the local queue sky-high? On Oct 5, 2007, at 3:54 PM, Kyle Quillen wrote: Is it possible to just purge the whole queue? I know it means lost email but I just bit the bullet and did it. Are these spam messages that your getting hit with an open relay? I had thousands of @yahoo.com.tw emails in mine. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 3:51 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Queued into surrender qmHandle -M deleted what appeared to be about 50 messages. There are still thousands of messages in the local queue. No mail is being delivered to the users. No mail is going out. This is really bad. On Oct 5, 2007, at 2:35 PM, Kyle Quillen wrote: Try this command qmHandle -M That will delete all of the email that was not able to be sent. See if that lessens the queue. The other day I just ended up deleting the entire queue. And all was well. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 2:33 PM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Queued into surrender I changed my queue lifetime to one hour (3600) qmHandle was useful for seeing what is in the queue. But I still can't get it to /process/ the queue. On Oct 5, 2007, at 2:00 PM, Kyle Quillen wrote: Hello, I just had this issue the other day. Have you looked at the tool qmHandle If you just type that in it will give you a list of options on how to deal with the queue. What do you have your queue lifetime set to? If you have Qmail toaster plus installed then you have qmHandle. Thanks Q -Original Message- From: Roxanne Sandesara [mailto:[EMAIL PROTECTED] Sent: Friday, October 05, 2007 1:58 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Queued into surrender My qmail-toaster seems to have hundreds, if not thousands of messages undelivered and sitting in the queue. This has reached the point that local messages, from users who are on the server to other users on the server, are not being delivered, even hours after they have been sent. I have followed the instructions on http:// wiki.qmailtoaster.com/index.php/Queuelifetime as well as attempting a reboot of the server. Nothing seems to clear out the queue, force the system to deliver or give up, and move on. Does anyone have any other suggestions. My users are frantic. They live by their email communication, and with that down, they are giving me no peace, and I currently have no useful solutions. - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: qmailtoaster-list- [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED
Re: [qmailtoaster] Queued into surrender
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 http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: qmailtoaster-list- [EMAIL PROTECTED] - QmailToaster hosted by: VR Hosted http://www.vr.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
