I think I will try to use the symlik and then run qmail queue-fix program.
I had nice results a little bit ago moving a whole system to another
drive. I tarred everything and opened to the filesystems in new disk.
The only thing which didnt work was again qmail trigger file (I assumed
but might be something else) I ran the qmail-queue-fix program and
everything is working.
Now I think that trigger file was not the problem but the inode numbers
which are changed when I tar the directory and open back was.
Also now I know that I can just move the queue directory symlink it then
run qmail queue-fix program and everything will work.
Thanks
Evren
On Fri, 22 Aug 2003, Peter Palmreuther wrote:
Hi Evren,
Please don't send any reply to me privately unless explicitely
requested. I do read the list (else I wouldn't have been able to answer
your question) and I don't need two or more copies of one mail.
Thank you.
On Fri, 22 Aug 2003 12:17:36 +0300 (WET) Evren Yurtesen wrote:
[quoting fixed]
I know this is not the right list but do you know how can I change the
qmail's queue directory nicely? :) Is a little symlink to another
location would do? or would sacrifice too much of performance?
It should work and not impact on performance /too/ much, but why do you
want to change the location?
But be aware the queue is empty before you switch over, files names used
in queue directory are 'Inode-bound', simply moving the queue files will
break them.
I want to change it because current queue directory is in /var/qmail/queue
and I figured out that the 256mbyte in /var filesystem might be
insufficient if there comes too much emails with attachments from my
customers at the same time. Plus the undeliverable ones etc.
What about an extra partition for '/var/qmail/queue' that's simply
mounted there? No need for symlinking, lots of space, not affected by a
possible overflow in '/var/log', etc , etc ...
I thought I might use this qmail queue fix tool from qmail web page. I
simply dont know how to empty the queue ?
Stop the SMTPD for no new mails coming in. Make your best attempt to
stop processes that might inject mails locally.
Send 'qmail-send' process an 'ALRM' signal. Wait.
You'll /NOT/ loose any external mail that can't be delivered due to the
fact the SMTP is down, /IF/ the foreing MTAs are configured correctly.
They should keep the message in queue for several days until your MTA
is up again (if you don't even have a backup MX for your domain).
Previously I had bad experience with lock/trigger file in queue directory.
Maybe because 'qmail-send' still ran when you did something on this
file? It's 'fifo', a 'name pipe' and qmail-send keeps a handle opened on
this file. Stop qmail-send before moving anything and if you've any
trouble moving 'lock/trigger' as is use 'mkfifo' to recreate it at
it's new location.
I also wonder how to regenerate it with correct options in the new
filesystem. :) There was supposed to be a make command for that but :)
'make setup' in qmail source tree will generate the queue structure.
But you can easliy
pushd /var/qmail/queue
find . -type d | \
(cd /path/to/new/queue/dir;
while read $DIRECTORY; do mkdir $DIRECTORY \
chown --reference=/var/qmail/queue/$DIRECTORY \
chmod --reference=/var/qmail/queue/$DIRETORY ;
done)
It's then two files to copy: './lock/{sendmutex,tcpto}' and the fifo
'./lock/trigger' that has to be created and you're done with creating a
new, clean qmail-queue-structure.
--
Ciao,
Pit