Re: [qmailtoaster] queue not porcessed
Precisely. I don't know if it's really worth it at this point. We know what the problem is, and have a permanent fix for it. In addition, I'll be adding an execution of queue_repair.py to qtp-newmodel, just to make sure things are kept clean. Kent Busbee wrote: something like queue_repair.py $@ | tee -a /var/log/queue_repair See response above; Eric Shubert wrote: No, it simply sends output to the terminal. I suppose that a customized version for QTP which would tee off a log file automatically would be nice. That would be pretty simple to do with a script wrapper. Would anyone like to take a shot at writing a qtp-queue-repair script that would do this? It would simply need to pass any parameters it gets along to the python script, and tee the output to a log file somewhere. Maxwell Smart wrote: Is the queue_repair logged? If so I can forward it to you. Tell me what file you want. Eric Shubert wrote: Thanks Lucian. We still don't know for sure how the queues became borked. Nothing in that area has changed that we know of. At any rate, if anyone experiences delayed deliveries after an update, the thing to do would be to stop qmail and run the queue_repair.py tool. It would be helpful if someone with the error would post the results from their queue_repair.py run. I do have one such output and would like to compare it to others. Perhaps that would provide a clue. Lucian Cristian wrote: it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric Shubert wrote: We're guessing here, but it's possible that qmail didn't terminate successfully (or cleanly) when the update was actually done. qtp-newmodel presently simply waits 5 seconds then displays the result of qmailctl stat. Does anyone happen to remember seeing anything other than 'not running', like perhaps 'want down', for any services that were listed when qmail was stopped just before the upgrade was performed??? I'm going to enhance qtp-newmodel to wait for 'not running' status for all services before proceeding with the update. This should ensure that everything is stopped before the update is done. Whether it keeps the queue corruption from happening any more is anyone's guess. I think there's a good chance of it though. Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- -Eric 'shubes' -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
something like queue_repair.py $@ | tee -a /var/log/queue_repair See response above; Eric Shubert wrote: > No, it simply sends output to the terminal. > > I suppose that a customized version for QTP which would tee off a log > file automatically would be nice. That would be pretty simple to do with > a script wrapper. Would anyone like to take a shot at writing a > qtp-queue-repair script that would do this? It would simply need to pass > any parameters it gets along to the python script, and tee the output to > a log file somewhere. > > Maxwell Smart wrote: >> Is the queue_repair logged? If so I can forward it to you. Tell me >> what file you want. >> >> Eric Shubert wrote: >>> Thanks Lucian. >>> >>> We still don't know for sure how the queues became borked. Nothing in >>> that area has changed that we know of. >>> >>> At any rate, if anyone experiences delayed deliveries after an update, >>> the thing to do would be to stop qmail and run the queue_repair.py >>> tool. >>> >>> It would be helpful if someone with the error would post the results >>> from their queue_repair.py run. I do have one such output and would >>> like to compare it to others. Perhaps that would provide a clue. >>> >>> Lucian Cristian wrote: it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric Shubert wrote: > We're guessing here, but it's possible that qmail didn't terminate > successfully (or cleanly) when the update was actually done. > qtp-newmodel presently simply waits 5 seconds then displays the > result of qmailctl stat. > > Does anyone happen to remember seeing anything other than 'not > running', like perhaps 'want down', for any services that were > listed when qmail was stopped just before the upgrade was > performed??? > > I'm going to enhance qtp-newmodel to wait for 'not running' status > for all services before proceeding with the update. This should > ensure that everything is stopped before the update is done. Whether > it keeps the queue corruption from happening any more is anyone's > guess. I think there's a good chance of it though. > > Lucian Cristian wrote: >> Hi >> >> thanks for info, I tried it some seconds ago, after I sent the mail >> to mailing list occurred to me to test queue repair, and it seems >> to work >> >> it was a qtp-newmodel upgrade and the x64 was a clean install. >> the x86 versions seems to lag, I'll test a bit more >> >> Regards >> Lucian >> >> Jake Vickers wrote: >>> Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? >>> Is this after a recent upgrade? >>> Try running the queue-repair.py script to fix issues with the >>> queue. >>> >>> > >>> >> >> - >> Qmailtoaster is sponsored by Vickers Consulting Group >> (www.vickersconsulting.com) >> Vickers Consulting Group offers Qmailtoaster support and >> installations. >> If you need professional help with your setup, contact them today! >> - >> Please visit qmailtoaster.com for the latest news, updates, and >> packages. >> >> To unsubscribe, e-mail: >> qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: >> qmailtoaster-list-h...@qmailtoaster.com >> >> >> > > > -- > -Eric 'shubes' > > > - > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and > installations. > If you need professional help with your setup, contact them today! > - > Please visit qmailtoaster.com for the latest news, updates, and > packages. > > To unsubscribe, e-mail: > qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > > Kent Busbee Director of Technology Northlake Christian School - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! --
Re: [qmailtoaster] queue not porcessed
Thanks Kent, that's helpful. I hope to be looking at these in more detail later today. Jake and I suspect that these permissions are not a problem, but I hope to fix them one way or another (so there's no message if they're not). The trigger pipe/file was definitely a problem though, which is caused by the 1.3.19 update of the qmail-toaster package. queue_repair.py remedies the problem, but we hope to have a permanent fix available in the next few days. Kent Busbee wrote: After reading these I checked mine and did have errors. I could not scroll back very far but did have permissions problems: checking split locations... queue/mess/1/11175402 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/11175402 ownership 7794:2108 queue/mess/1/11175195 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/11175195 ownership 7794:2108 queue/mess/1/10354693 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/10354693 ownership 7794:2108 queue/mess/1/11175747 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/11175747 ownership 7794:2108 queue/mess/3/11175818 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/3/11175818 ownership 7794:2108 queue/mess/3/11175312 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/3/11175312 ownership 7794:2108 queue/mess/3/11175726 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/3/11175726 ownership 7794:2108 queue/mess/4/10354696 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/4/10354696 ownership 7794:2108 queue/mess/5/11175751 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/5/11175751 ownership 7794:2108 queue/mess/5/11175314 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/5/11175314 ownership 7794:2108 queue/mess/6/11175775 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/6/11175775 ownership 7794:2108 queue/mess/6/11175821 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/6/11175821 ownership 7794:2108 queue/mess/6/11175660 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/6/11175660 ownership 7794:2108 queue/mess/8/11175800 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/8/11175800 ownership 7794:2108 queue/mess/10/11175756 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/10/11175756 ownership 7794:2108 queue/mess/14/11175070 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/14/11175070 ownership 7794:2108 queue/mess/15/11175738 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/15/11175738 ownership 7794:2108 queue/mess/16/11175808 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/16/11175808 ownership 7794:2108 queue/mess/16/11175854 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/16/11175854 ownership 7794:2108 queue/mess/17/11175740 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/17/11175740 ownership 7794:2108 queue/mess/17/11175395 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/17/11175395 ownership 7794:2108 queue/mess/18/11175787 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/18/11175787 ownership 7794:2108 queue/mess/19/11175834 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/19/11175834 ownership 7794:2108 queue/mess/20/11175812 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/20/11175812 ownership 7794:2108 queue/mess/20/10354689 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/20/10354689 ownership 7794:2108 queue/mess/21/11175744 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/21/11175744 ownership 7794:2108 queue/mess/22/10354691 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/22/10354691 ownership 7794:2108 See response above; Eric Shubert wrote: No, it simply sends output to the terminal. I suppose that a customized version for QTP which would tee off a log file automatically would be nice. That would be pretty simple to do with a script wrapper. Would anyone like to take a shot at writing a qtp-queue-repair script that would do this? It would simply need to pass any parameters it gets along to the python script, and tee the output to a log file somewhere. Maxwell Smart wrote: Is the queue_repair logged? If so I can forward it to you. Tell me what file you want. Eric Shubert wrote: Thanks Lucian. We still don't know for sure how the queues became borked. Nothing in that area has changed that we know of. At any rate, if anyone experiences delayed deliveries after an update, the thing to do would be to stop qmail and run the queue_repair.py tool. It would be helpful if someone with the error would post the results from their queue_repair.py run. I do have one such output and would like to compare it to others. Perhaps that would provide a clue. Lucian Cristian wrote: it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric
Re: [qmailtoaster] queue not porcessed
After reading these I checked mine and did have errors. I could not scroll back very far but did have permissions problems: checking split locations... queue/mess/1/11175402 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/11175402 ownership 7794:2108 queue/mess/1/11175195 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/11175195 ownership 7794:2108 queue/mess/1/10354693 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/10354693 ownership 7794:2108 queue/mess/1/11175747 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/1/11175747 ownership 7794:2108 queue/mess/3/11175818 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/3/11175818 ownership 7794:2108 queue/mess/3/11175312 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/3/11175312 ownership 7794:2108 queue/mess/3/11175726 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/3/11175726 ownership 7794:2108 queue/mess/4/10354696 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/4/10354696 ownership 7794:2108 queue/mess/5/11175751 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/5/11175751 ownership 7794:2108 queue/mess/5/11175314 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/5/11175314 ownership 7794:2108 queue/mess/6/11175775 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/6/11175775 ownership 7794:2108 queue/mess/6/11175821 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/6/11175821 ownership 7794:2108 queue/mess/6/11175660 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/6/11175660 ownership 7794:2108 queue/mess/8/11175800 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/8/11175800 ownership 7794:2108 queue/mess/10/11175756 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/10/11175756 ownership 7794:2108 queue/mess/14/11175070 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/14/11175070 ownership 7794:2108 queue/mess/15/11175738 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/15/11175738 ownership 7794:2108 queue/mess/16/11175808 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/16/11175808 ownership 7794:2108 queue/mess/16/11175854 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/16/11175854 ownership 7794:2108 queue/mess/17/11175740 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/17/11175740 ownership 7794:2108 queue/mess/17/11175395 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/17/11175395 ownership 7794:2108 queue/mess/18/11175787 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/18/11175787 ownership 7794:2108 queue/mess/19/11175834 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/19/11175834 ownership 7794:2108 queue/mess/20/11175812 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/20/11175812 ownership 7794:2108 queue/mess/20/10354689 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/20/10354689 ownership 7794:2108 queue/mess/21/11175744 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/21/11175744 ownership 7794:2108 queue/mess/22/10354691 ownership 7794:0, should be qmailq:qmail fixed, queue/mess/22/10354691 ownership 7794:2108 See response above; Eric Shubert wrote: > No, it simply sends output to the terminal. > > I suppose that a customized version for QTP which would tee off a log > file automatically would be nice. That would be pretty simple to do with > a script wrapper. Would anyone like to take a shot at writing a > qtp-queue-repair script that would do this? It would simply need to pass > any parameters it gets along to the python script, and tee the output to > a log file somewhere. > > Maxwell Smart wrote: >> Is the queue_repair logged? If so I can forward it to you. Tell me >> what file you want. >> >> Eric Shubert wrote: >>> Thanks Lucian. >>> >>> We still don't know for sure how the queues became borked. Nothing in >>> that area has changed that we know of. >>> >>> At any rate, if anyone experiences delayed deliveries after an update, >>> the thing to do would be to stop qmail and run the queue_repair.py >>> tool. >>> >>> It would be helpful if someone with the error would post the results >>> from their queue_repair.py run. I do have one such output and would >>> like to compare it to others. Perhaps that would provide a clue. >>> >>> Lucian Cristian wrote: it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric Shubert wrote: > We're guessing here, but it's possible that qmail didn't terminate > successfully (or cleanly) when the update was actually done. > qtp-newmodel presently simply waits 5 seconds then displays the > result of qmailctl stat. > > Does anyone happen to remember seeing anything other than 'not > running', like perhaps 'want down', for a
Re: [qmailtoaster] queue not porcessed
Jake Vickers wrote: Lucian Cristian wrote: I don't have it anymore, but socket file "trigger" from queue/lock was missing and permissions on some files Same here on one I fixed for someone this morning. "No such file or directory: queue/lock/trigger" I'll look at the last changes in the spec file a little more in depth and see if timing there may have been an issue. I would be curious to see if anyone who updated using a different method than qtp-newmodel experienced the same issue. That would narrow it down a little. queue/lock/trigger is the named pipe that's not supposed to be installed in the sandbox, but it should be in the real install. It's no longer listed in the 'files' section of the spec file, so it doesn't belong to the package any more. I'm checking some things... -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Lucian Cristian wrote: I don't have it anymore, but socket file "trigger" from queue/lock was missing and permissions on some files Same here on one I fixed for someone this morning. "No such file or directory: queue/lock/trigger" I'll look at the last changes in the spec file a little more in depth and see if timing there may have been an issue. I would be curious to see if anyone who updated using a different method than qtp-newmodel experienced the same issue. That would narrow it down a little. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
No, it simply sends output to the terminal. I suppose that a customized version for QTP which would tee off a log file automatically would be nice. That would be pretty simple to do with a script wrapper. Would anyone like to take a shot at writing a qtp-queue-repair script that would do this? It would simply need to pass any parameters it gets along to the python script, and tee the output to a log file somewhere. Maxwell Smart wrote: Is the queue_repair logged? If so I can forward it to you. Tell me what file you want. Eric Shubert wrote: Thanks Lucian. We still don't know for sure how the queues became borked. Nothing in that area has changed that we know of. At any rate, if anyone experiences delayed deliveries after an update, the thing to do would be to stop qmail and run the queue_repair.py tool. It would be helpful if someone with the error would post the results from their queue_repair.py run. I do have one such output and would like to compare it to others. Perhaps that would provide a clue. Lucian Cristian wrote: it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric Shubert wrote: We're guessing here, but it's possible that qmail didn't terminate successfully (or cleanly) when the update was actually done. qtp-newmodel presently simply waits 5 seconds then displays the result of qmailctl stat. Does anyone happen to remember seeing anything other than 'not running', like perhaps 'want down', for any services that were listed when qmail was stopped just before the upgrade was performed??? I'm going to enhance qtp-newmodel to wait for 'not running' status for all services before proceeding with the update. This should ensure that everything is stopped before the update is done. Whether it keeps the queue corruption from happening any more is anyone's guess. I think there's a good chance of it though. Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Is the queue_repair logged? If so I can forward it to you. Tell me what file you want. Eric Shubert wrote: > Thanks Lucian. > > We still don't know for sure how the queues became borked. Nothing in > that area has changed that we know of. > > At any rate, if anyone experiences delayed deliveries after an update, > the thing to do would be to stop qmail and run the queue_repair.py tool. > > It would be helpful if someone with the error would post the results > from their queue_repair.py run. I do have one such output and would > like to compare it to others. Perhaps that would provide a clue. > > Lucian Cristian wrote: >> it was a clean shutdown in my case, I don't know what happened, >> anyway now it's ok >> >> Regards >> Lucian >> >> Eric Shubert wrote: >>> We're guessing here, but it's possible that qmail didn't terminate >>> successfully (or cleanly) when the update was actually done. >>> qtp-newmodel presently simply waits 5 seconds then displays the >>> result of qmailctl stat. >>> >>> Does anyone happen to remember seeing anything other than 'not >>> running', like perhaps 'want down', for any services that were >>> listed when qmail was stopped just before the upgrade was performed??? >>> >>> I'm going to enhance qtp-newmodel to wait for 'not running' status >>> for all services before proceeding with the update. This should >>> ensure that everything is stopped before the update is done. Whether >>> it keeps the queue corruption from happening any more is anyone's >>> guess. I think there's a good chance of it though. >>> >>> Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: > Lucian Cristian wrote: >> Hi everyone I have problems with the queue on to different >> systems, the queue will not be processed as soon as possible, >> there is some lag, if a do a qmailqtl restart the mails will be >> processed if not I have to wait a random time >> >> I've read about "qmail silly syndrome" is this the problem ? >> > > Is this after a recent upgrade? > Try running the queue-repair.py script to fix issues with the queue. > > >>> >>> > > - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
I don't have it anymore, but socket file "trigger" from queue/lock was missing and permissions on some files Lucian Eric Shubert wrote: Thanks Lucian. We still don't know for sure how the queues became borked. Nothing in that area has changed that we know of. At any rate, if anyone experiences delayed deliveries after an update, the thing to do would be to stop qmail and run the queue_repair.py tool. It would be helpful if someone with the error would post the results from their queue_repair.py run. I do have one such output and would like to compare it to others. Perhaps that would provide a clue. Lucian Cristian wrote: it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric Shubert wrote: We're guessing here, but it's possible that qmail didn't terminate successfully (or cleanly) when the update was actually done. qtp-newmodel presently simply waits 5 seconds then displays the result of qmailctl stat. Does anyone happen to remember seeing anything other than 'not running', like perhaps 'want down', for any services that were listed when qmail was stopped just before the upgrade was performed??? I'm going to enhance qtp-newmodel to wait for 'not running' status for all services before proceeding with the update. This should ensure that everything is stopped before the update is done. Whether it keeps the queue corruption from happening any more is anyone's guess. I think there's a good chance of it though. Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. __ Information from ESET NOD32 Antivirus, version of virus signature database 4455 (20090924) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Thanks Lucian. We still don't know for sure how the queues became borked. Nothing in that area has changed that we know of. At any rate, if anyone experiences delayed deliveries after an update, the thing to do would be to stop qmail and run the queue_repair.py tool. It would be helpful if someone with the error would post the results from their queue_repair.py run. I do have one such output and would like to compare it to others. Perhaps that would provide a clue. Lucian Cristian wrote: it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric Shubert wrote: We're guessing here, but it's possible that qmail didn't terminate successfully (or cleanly) when the update was actually done. qtp-newmodel presently simply waits 5 seconds then displays the result of qmailctl stat. Does anyone happen to remember seeing anything other than 'not running', like perhaps 'want down', for any services that were listed when qmail was stopped just before the upgrade was performed??? I'm going to enhance qtp-newmodel to wait for 'not running' status for all services before proceeding with the update. This should ensure that everything is stopped before the update is done. Whether it keeps the queue corruption from happening any more is anyone's guess. I think there's a good chance of it though. Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
it was a clean shutdown in my case, I don't know what happened, anyway now it's ok Regards Lucian Eric Shubert wrote: We're guessing here, but it's possible that qmail didn't terminate successfully (or cleanly) when the update was actually done. qtp-newmodel presently simply waits 5 seconds then displays the result of qmailctl stat. Does anyone happen to remember seeing anything other than 'not running', like perhaps 'want down', for any services that were listed when qmail was stopped just before the upgrade was performed??? I'm going to enhance qtp-newmodel to wait for 'not running' status for all services before proceeding with the update. This should ensure that everything is stopped before the update is done. Whether it keeps the queue corruption from happening any more is anyone's guess. I think there's a good chance of it though. Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. __ Information from ESET NOD32 Antivirus, version of virus signature database 4455 (20090924) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
We're guessing here, but it's possible that qmail didn't terminate successfully (or cleanly) when the update was actually done. qtp-newmodel presently simply waits 5 seconds then displays the result of qmailctl stat. Does anyone happen to remember seeing anything other than 'not running', like perhaps 'want down', for any services that were listed when qmail was stopped just before the upgrade was performed??? I'm going to enhance qtp-newmodel to wait for 'not running' status for all services before proceeding with the update. This should ensure that everything is stopped before the update is done. Whether it keeps the queue corruption from happening any more is anyone's guess. I think there's a good chance of it though. Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. -- -Eric 'shubes' - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Maxwell Smart wrote: Any ideas what caused this yet? Some suspicions and we're investigating further. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Same issue I had. Lucian Cristian wrote: > It seems that the problems is solved, there was some file missing and > some permission problems on queue dir > > Regards > Lucian > > Lucian Cristian wrote: >> Hi >> >> thanks for info, I tried it some seconds ago, after I sent the mail >> to mailing list occurred to me to test queue repair, and it seems to >> work >> >> it was a qtp-newmodel upgrade and the x64 was a clean install. >> the x86 versions seems to lag, I'll test a bit more >> >> Regards >> Lucian >> >> Jake Vickers wrote: >>> Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? >>> >>> Is this after a recent upgrade? >>> Try running the queue-repair.py script to fix issues with the queue. >>> >>> >>> - >>> >>> Qmailtoaster is sponsored by Vickers Consulting Group >>> (www.vickersconsulting.com) >>>Vickers Consulting Group offers Qmailtoaster support and >>> installations. >>> If you need professional help with your setup, contact them today! >>> - >>> >>> Please visit qmailtoaster.com for the latest news, updates, and >>> packages. >>> To unsubscribe, e-mail: >>> qmailtoaster-list-unsubscr...@qmailtoaster.com >>> For additional commands, e-mail: >>> qmailtoaster-list-h...@qmailtoaster.com >>> >>> >>> >>> >>> __ Information from ESET NOD32 Antivirus, version of virus >>> signature database 4465 (20090928) __ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >> >> >> >> __ Information from ESET NOD32 Antivirus, version of virus >> signature database 4465 (20090928) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> - >> >> Qmailtoaster is sponsored by Vickers Consulting Group >> (www.vickersconsulting.com) >>Vickers Consulting Group offers Qmailtoaster support and >> installations. >> If you need professional help with your setup, contact them today! >> - >> >> Please visit qmailtoaster.com for the latest news, updates, and >> packages. >> To unsubscribe, e-mail: >> qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: >> qmailtoaster-list-h...@qmailtoaster.com >> >> >> >> >> __ Information from ESET NOD32 Antivirus, version of virus >> signature database 4465 (20090928) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> > > > > __ Information from ESET NOD32 Antivirus, version of virus > signature database 4465 (20090928) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > - > > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) >Vickers Consulting Group offers Qmailtoaster support and > installations. > If you need professional help with your setup, contact them today! > - > > Please visit qmailtoaster.com for the latest news, updates, and > packages. > To unsubscribe, e-mail: > qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
It seems that the problems is solved, there was some file missing and some permission problems on queue dir Regards Lucian Lucian Cristian wrote: Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4465 (20090928) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4465 (20090928) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4465 (20090928) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4465 (20090928) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Hi thanks for info, I tried it some seconds ago, after I sent the mail to mailing list occurred to me to test queue repair, and it seems to work it was a qtp-newmodel upgrade and the x64 was a clean install. the x86 versions seems to lag, I'll test a bit more Regards Lucian Jake Vickers wrote: Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4465 (20090928) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4465 (20090928) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Any ideas what caused this yet? Jake Vickers wrote: > Lucian Cristian wrote: >> Hi everyone I have problems with the queue on to different systems, >> the queue will not be processed as soon as possible, there is some >> lag, if a do a qmailqtl restart the mails will be processed if not I >> have to wait a random time >> >> I've read about "qmail silly syndrome" is this the problem ? >> > > Is this after a recent upgrade? > Try running the queue-repair.py script to fix issues with the queue. > > > - > > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) >Vickers Consulting Group offers Qmailtoaster support and > installations. > If you need professional help with your setup, contact them today! > - > > Please visit qmailtoaster.com for the latest news, updates, and > packages. > To unsubscribe, e-mail: > qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > > - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] queue not porcessed
Lucian Cristian wrote: Hi everyone I have problems with the queue on to different systems, the queue will not be processed as soon as possible, there is some lag, if a do a qmailqtl restart the mails will be processed if not I have to wait a random time I've read about "qmail silly syndrome" is this the problem ? Is this after a recent upgrade? Try running the queue-repair.py script to fix issues with the queue. - Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! - Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com