Hi,
I read the documentation regarding qmail mail queues. Some of that documentation is on DJB's site. Other documentation can be found in qmail's INTERNALS file. It seems fairly clear.
But I am having a problem with something I'm trying to do. DJB says that making snapshots of mail queues is very difficult. One of the problems he lists is that since the queue can be busy, you never know exactly what you've captured. Another problem he lists is with restoring the queue: the file names and inodes must match on a qmail queue (for items in /mess), and therefore it would be hard to restore a qmail queue.
However. What if you do /var/qmail/bin/qmailctl stop, *then* tar up the queue (then, the tar queue should be in the same S-state as the real queue, and that's valid, and not in-transition). Later, with qmail still stopped, you remove the old qmail queue, and untar the old queue in its place. Then, to be very diligent, you meticulously clean up the queue by renaming every file in mess to match its *new* inode, and then go about fixing up every file in bounce/, info/, intd/, local/, remote/ and todo/ to be consistent.
Now, you have a mail queue that is in the same S-state (listed in INTERNALS) as the original queue, with inode-matching mess names.
My problem: this new queue will not process. Sometimes, qmail will deliver a handful of messages from this queue. In any event, it never delivers all the messages. Just a few.
My question: what did I do wrong? Is there a solution?
Thanks in advance,
-Eddie
p.s I note that the undelivered email is all in state S5. I was worried about this. However, notably, the messages in the untampered-with queue are also in this state when qmailctl stop was run. I can't see how this differentiates my queue with the untampered-with one, since after reboot, there's no way qmail could have recorded any interesting message state except in the filesystem itself.
