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: [email protected]
For additional commands, e-mail: [email protected]
