Re: [exim] Backup/Restore Messages in the Input Queue

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Heiko Schlittermann
Data:  
Para: exim-users
Assunto: Re: [exim] Backup/Restore Messages in the Input Queue
Patrick Porteous via Exim-users <exim-users@???> (So 16 Okt 2022 12:24:27 CEST):
> Hello,
>
> I am trying to troubleshoot a sending issue on my server.  I have a few
> hundred messages that are stuck in the /var/spool/exim/input queue.  Can I
> shutdown the exim server process and move those files to another location
> and then move them back if that doesn't resolve the issue?  Here are the
> exact steps I plan to follow:


Once there is no Exim process running anymore, it is safe to remove/move
the queued files (there are two files per message, -H, and -D). In a
perfect world you'll move/remove the msglogs too.

> 1. Shutdown Exim
> 2. Move all messages in /var/spool/exim/input to a backup location
> 3. Start Exim server
> 4. Send a few test messages to see if my sending issue is corrected
> 5. Shutdown Exim
> 6. Move the messages back into the /var/spool/exim/input folder a few
>    at a time
> 7. Start Exim server
> 8. Manually force a queue run


Without deeper insight into how Exim works, this approach is safe. There
are some shortcuts possible, but this requires knowledge about the
inner workings (locked files, …)

If you want to operatate on a more abstract level (as the spool
hierarchy should be considered as a kind of black box to the avarage
operator), you can use Exim's named queues feature and move the messages
into an alternative queue using the Exim command line:

exim -MG hold ID...

later you can inspect this queue:

exim -qGhold -bp

and move the messages back

exim -qGhold -MG '' ID…

> My goal is retain the queued messages and not force my users resend the
> messages that are hung in the queue presently.  My suspicion is that I have
> a malformed message in the queue that is causing the other messages to hang
> up.


The queue runners that process your queued messages should not fail
totally if there is one "bad" messages, as they start at random messages
in your queue and should manage to empty the queue over the time, just
leaving the bad message there.

    Best regards from Dresden/Germany
    Viele Grüße aus Dresden
    Heiko Schlittermann
--
 SCHLITTERMANN.de ---------------------------- internet & unix support -
 Heiko Schlittermann, Dipl.-Ing. (TU) - {fon,fax}: +49.351.802998{1,3} -
 gnupg encrypted messages are welcome --------------- key ID: F69376CE -