Command to view the queue
To view the exim mail queue issue the following command:
If exim is in /usr/sbin and /usr/sbin is not in your path, you’ll need to prefix the command with the full path like so:
The outut from the above commands will look something like so:
4d 1.2K 1Ka6u5-00032Z-Eb <firstname.lastname@example.org>
62h 1.2K 1KaRH0-0007QZ-B5 <email@example.com>
3h 22K 1KbLHr-0004ev-An <firstname.lastname@example.org>
In the above example “email@example.com” is the email address the email is being sent from and firstname.lastname@example.org is the address being sent to. Normally these would be real email addresses but I’ve changed them for the purposes of this post.
The 4d, 62h and 3h values indicate how long the email message has been in the queue: 4 days, 62 hours and 3 hours respectively.
The x.xK values are the message size.
And the 1Ka6u5-00032Z-Eb etc is the message id and is also the filename of the message on disk, which you will find in /var/spool/exim/msglog and /var/spool/exim/input (the directories may vary depending on your Linux/Unix distribution and/or compiled in settings).
Finding the files with the find command
Using the “find” command you could do this to locate all the relevent files:
find /var/spool/exim -name "1Ka6u5-00032Z-Eb*"
which would display something like this:
Command to flush the exim queue
There are two ways to flush the exim mail queue:
This will then process the mail queue. I had a look at the exim log file and the mail queue itself (I’ll be posting how to view what’s in the exim mail queue on Tuesday) after flushing the queue and the emails were still stuck there.
Additional flags to force mail send
Another quick look at the exim man page and I discovered the following options:
-qf = If one f flag is present, a delivery attempt is forced for each non-frozen message, whereas without f only those non-frozen addresses that have passed their retry times are tried.
-qff = If ff is present, a delivery attempt is forced for every message, whether frozen or not.
So I then ran this:
And the messages that were stuck in the queue were flushed and delivered. My customer reported back to me a few minutes later that their emails had been received.
Path to exim command
Note that the exim command is probably in /usr/sbin and you may need to use the whole path as well as the command to run it. If this is the case then do this:
Delete a single message from the exim mail queue
Use mailq / exim -bp to show the mail queue, e.g.:
0m 528 1XoIxD-0001rc-8J
And then run exim -Mrm [message id] to delete the specific message:
exim -Mrm 1XoIxD-0001rc-8J
If the message is successfully deleted, you’ll see this:
Message 1XoIxD-0001rc-8J has been removed
If exim is currently processing the message, you’ll see this and it won’t be deleted:
Message 1XoIxD-0001rc-8J is locked
You either need to wait and try again later, or get the id of the process which is currently processing the message, kill it, and then run the command again (e.g. “ps ax 1XoIxD-0001rc-8J” and then “kill -9 [process id/s]). It’s probably not recommended that you kill the process.
Delete all messages in the exim mail queue
Running “exiqgrep -i” returns all the message ids for queued emails; pipe that through “exim -Mrm” and all the messages will be deleted, with the same caveat as above: if exim is currently processing a message, that one will not be deleted so you need to try again later.
exiqgrep -i | xargs exim -Mrm
And the result, if one could be removed and another one couldn’t:
Message 1XoJ1U-0001sC-ME has been removed
Message 1XoJ1i-0001sQ-UJ is locked