- Chris Hardie <[EMAIL PROTECTED]>:
| Howdy; please help ASAP: We're running Qmail on FreeBSD 2.2.8.
| Someone sent a 17 MB message to one of our users. /var, where qmail
| is located, is only a 30 MB partition, and with that message sitting
| in the queue, only has about 3 MB left on it.
|
| In the maillog, the message
|
| deferral: Unable_to_forward_message :_qq_write_error_or_disk_full_(#4.3.0)./
|
| appears repeatedly. There's plenty of space on the user's partition
| and their quota will allow for the message just fine. It appears
| that qmail somehow needs to re-write the message somewhere in it's
| own hierarchy on the same partition before it can forward it on.
Yes indeed, forwarding a message means requeueing it.
| I tried reducing the queue lifetime so the message would bounce, but
| qmail can't bounce it either, the same messages of "file system
| full" keep appearing.
No surprise there.
| I tried (much to your dismay) to move the queue directory to another
| partition, and got an error message at startup about "cannot start:
| unable to open mutex" so I didn't pursue that any further (can
| anyone say what "mutex" is?)
Ouch. Moving the queue directory is *dangerous*: There is not only
the special files in queue/lock/, but certain files need to have their
name and inode numbers matching, or else.
| So, I'd *really* like to know:
| 1) In the short term, is there a way to deliver or bounce this
| message without just deleting the queue file manually?
That's what I have done in similar situations. Stop the queue, move
all the files concerning the big message to a different file system,
and restart qmail. Now at least other mail can flow freely again.
Second, figure out the real destination address of the the problem
message and reinject it manually using
qmail-inject -a -f$SENDER $RECIPIENT
where you replace $SENDER and $RECIPIENT by the envelope sender and
recipient, respectively (you can find these in the other files
associated with the message, namely info/*/# and local/*/#. Except,
of course, you must now supply the forwarding address, so the message
doesn't have to be regurgitated through the queue again.
| 2) In general, did this problem arise because we improperly
| installed qmail to a small partition, or is there something about
| qmail that should be better in handling large messages (i.e. file
| system full problems) that it can't really handle?
I'll say a 30 MB partition is a mite small, yes. But also, it is true
that qmail doesn't gracefully handle the sort of situation you are
describing. Making it do so is not a trivial task, however.
| 3) If it's a disk space issue, is there a way to have the queue
| directory somewhere else or do we need to move the whole ball of
| wax?
I think there is no problem with having /var/qmail/queue being a
symlink to a directory on a different filesystem. On the other hand,
the queue at its largest is usually vastly larger than the rest of the
qmail files combined, so I would generally recommend moving the whole
shebang. In my opinion, mail is so important it pays to have a
separate filesystem for it. If you can spare a disk partition, mount
it on /var/qmail and put everything there. The best way to get it
back in operation, is to reinstall qmail (just run `make setup') and
then to copy everything from the old alias and control directories to
the new partition. Finally, if there were messages in the old queue,
copy them to the new queue (*all* files) and run the queue-fix program
(link at <URL:http://www.qmail.org/>). DON'T forget this last step,
as starting the qmail daemons, or even allowing qmail-queue to run
with the queue in a wrong state, can result in a corrupted queue and
lost mail.
| 4) Is there a way to restrict incoming/outgoing message size?
Incoming, yes. Use control/databytes (RTFM qmail-smtpd).
- Harald
