Another "email stuck in queue" question!

[monideth]

All,

I am trying to troubleshoot why certain emails are getting stuck in the queue - local and remote emails.

I am looking at the qmail-send/current logs and I see such entries:

warning: trouble opening local/162/1160240; will try again later

However, when I look in the above directory (/var/qmail/queue/local/162 - I assume this to be the directory!) I do not see the 1160240 message file.

Can somebody confirm this is the correct way to interpret the log!

Where else is the messages stored for qmail-send to look for and attempt to process.

Regards,

Mon

 

[thedaver]

Hrm, if you've been manually gutting messages from your queue you may have left some artifacts behind that confuse qmail into thinking it has items to deliver that don't have all pieces available now.

You probably need to find a queue repair tool, shutdown qmail and run it against your queue to cleanup these artifacts.

Also might be bad disk sectors?!

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[monideth]

I've been using the qmhandle tool to delete any problem messages. But I thought this was meant to properly handle emails in the qmail queue.

I am not aware of any disk problems on my server. But I will try to onvesitgate further.

I have been seeing alot of emails stuck in the queue. I previously usually delete them using qmhandle - but this time I want to sort this problem out as I am told by users that some emails are not getting sent out! Probably due to me deleting them! =(

I am also getting some emails that are stuck in the queue and gets resent until I delete them from the queue. Could this be problem with virus/spam checking processes?

Is there any further information/documentation on how qmail does its queue processing?

Regards,

Mon

 

[monideth]

(from

http://forum.qmailrocks.org/showthread.php?p=10750#post10750)

Hi,

I have been using qmhandle!

I think I realise what this error message is now. It seems that qmhandle is trying to restart the qmail processes:

./qmHandle -d1160255
Calling system script to terminate qmail...
Can't exec "/etc/init.d/qmail": No such file or directory at ./qmHandle line
137 (#1)
(W exec) A system(), exec(), or piped open call could not execute the
named program for the indicated reason. Typical reasons include: the
permissions were wrong on the file, the file wasn't found in
$ENV{PATH}, the executable in question was compiled for another
architecture, or the #! line in a script points to an interpreter that
can't be run for similar reasons. (Or maybe your system doesn't support
#! at all.)

Deleting message 177/1160255...
Qmail is already running again, so it won't be restarted.



Since the qmailrocks does not contain the init scripts qmhandle is looking for then it is not able to restart qmail - thus the qmail queue is being messed up!

Restarting qmail using 'qmailctrl restart' seem to resolve the problem.

This solves the problem of that error message.

However, I still had outgoing emails that were 'stuck'. I found this error mesage in the qmail logs:

TLS_found_no_client_cert_in_control/clientcert.pem/

It seems clientcert.pem is a link to servercert.pem - but its owner was root.root. I deleted the link and copied servercert.pem to clientcert.pem and set the owner and permissions appropriate to vpopmail.qmail

The TLS error seems to have disappeared and the emails delivered ot of the queue!

Regards,

Mon

 

[monideth]

I have changed the qmhandle script to use qmailctrl instead:

# While this is if you have a Debian GNU/Linux with its qmail package
#my ($stopqmail) = '/etc/init.d/qmail stop';
#my ($startqmail) = '/etc/init.d/qmail start';
my ($stopqmail) = 'qmailctrl stop';
my ($startqmail) = 'qmailctrl start';

Hopefully, this will work next time I delete an email using qmhandle!

Regards,

Mon

 

[monideth]

this is not my day....did you spot my deliberate spelling mistake? It should be 'qmailctl' and not 'qmailctrl'