Search


print PDF
The / partition is full due to Qmail queue

WARNING: This manual onlys concerns OVH RELEASE 1! Do not apply on a plesk server!

How to notice it?


Your mails are blocked, some services don't reboot any more (such as Apache).

Consequences


Full system partition (cf. SlashFull). Mails queue is too full, qmail doesn't manage to process it any more.

Causes

You didn't correctly managed /etc/tcp.smtp and your server has been used for a spam. Your disk is full. There is a lot of emails in the spool and you have only one solution: to queue again

Solution

Warning! This intervention is delicate and may lead up to the mails server not to work any more!

Proceed as follows in SSH:

# tail -f /var/log/qmail/current
@400000003f883c8c05961f54 alert: unable to append to bounce message; HELP! sleeping...
@400000003f883c96062e9a7c alert: unable to append to bounce message; HELP! sleeping...
@400000003f883ca006c73cb4 alert: unable to append to bounce message; HELP! sleeping...
# /var/qmail/bin/qmail-qstat
messages in queue: 12001
messages in queue but not yet preprocessed: 117
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 2016016 1913988 0 100% /
/dev/hda2 36977736 8967660 26131676 26% /home
none 257272 0 257272 0% /dev/shm


You have then to erase the directory and to start from the beginning. We stop qmail before:

# /etc/rc.d/init.d/qmail stop
stopping qmail [OK ]
# cd /var/qmail/
# ls -l
total 32
drwxr-sr-x 2 alias qmail 4096 jui 16 20:25 alias
drwxr-xr-x 2 root qmail 4096 jui 16 20:25 bin
drwxr-xr-x 2 root qmail 4096 jui 16 20:25 boot
drwxr-xr-x 2 root qmail 4096 oct 11 00:39 control
drwxr-xr-x 3 root qmail 4096 jui 16 20:25 doc
drwxr-xr-x 10 root qmail 4096 jui 16 20:25 man
drwxr-x
11 qmailq qmail 4096 jui 16 20:25 queue
drwxr-xr-x 2 root qmail 4096 oct 11 00:39 users
# rm -rf queue
# df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda1 2016016 834556 1079048 44% /
/dev/hda2 36977736 8967664 26131672 26% /home
none 257272 0 257272 0% /dev/sh


To queue again, we may use:
ftp://ftp.netmeridian.com/queue-fix.tar.gz
or
http://pyropus.ca/software/queue-repair/queue-repair-0.9.0.tar.gz

Let's take for example qmail-repair. We start by recovering and unzipping the soft:

[root@julien root]# mkdir /temp


[root@julien root]# cd /temp/


[root@julien temp]# wget http://pyropus.ca/software/queue-repair/queue-repair-0.9.0.tar.gz
--17:37:05-- http://pyropus.ca/software/queue-repair/queue-repair-0.9.0.tar.gz
=> `queue-repair-0.9.0.tar.gz'
Connection to pyropus.ca:80...Connected!
request HTTP, awaiting for a response...200 OK
Length: 13,913 [application/x-tar]

0K .......... ... 100% @ 23.47 KB/s

17:37:06 (23.47 KB/s) - `queue-repair-0.9.0.tar.gz' saved[13913/13913]

[root@julien temp]# tar xfz queue-repair-0.9.0.tar.gz

[root@julien temp]# cd queue-repair-0.9.0



Before all, let's test the manipulation in the current directory (to recreate a safe mail queue):

[root@julien queue-repair-0.9.0]# ./queue_repair.py -c -s 23 --no-bigtodo .



If everything goes right, you can check that the queue has been correctly recreated:

[root@julien queue-repair-0.9.0]# ls -l queue
total 36
drwx------ 2 qmails qmail 4096 tue 25 17:39 bounce
drwx------ 25 qmails qmail 4096 tue 25 17:39 info
drwx------ 2 qmailq qmail 4096 tue 25 17:39 intd
drwx------ 25 qmails qmail 4096 tue 25 17:39 local
drwxr-x--- 2 qmailq qmail 4096 tue 25 17:39 lock
drwxr-x--- 25 qmailq qmail 4096 tue 25 17:39 mess
drwx------ 2 qmailq qmail 4096 tue 25 17:39 pid
drwx------ 25 qmails qmail 4096 tue 25 17:39 remote
drwxr-x--- 2 qmailq qmail 4096 tue 25 17:39 todo



We can now get down to business, it means to create the mail queue really used by the mails server then check that everything is right.


[root@julien queue-repair-0.9.0] ./queue_repair.py -c -s 23 --no-bigtodo /var/qmail

[root@julien queue-repair-0.9.0]# ls -l /var/qmail/



Now, you just need to restart qmail (do not forget to set / to restart qmail).


# cd /
# /etc/rc.d/init.d/qmail start
Starting: qmail pop smtp
# echo test | mail oles@ovh.net
# tail -f /var/log/qmail/current
@400000003f883ce426b52c0c alert: unable to append to bounce message; HELP! sleeping...
@400000003f8840a31f2624dc alert: cannot start: unable to switch to queue directory
@400000003f88425517b081ac status: local 0/10 remote 0/20
@400000003f88426f0748a59c new msg 100179
@400000003f88426f074b1e6c info msg 100179: bytes 207 from qp 15605 uid 0
@400000003f88426f097eb3c4 starting delivery 1: msg 100179 to remote oles@ovh.net
@400000003f88426f0980da8c status: local 0/10 remote 1/20
@400000003f88426f1a6fd85c delivery 1: success: 213.186.33.73_accepted_message./Remote_host_said:_250_ok_1065894524_qp_30276/
@400000003f88426f1a7717d4 status: local 0/10 remote 0/20
@400000003f88426f1a7c4fc4 end msg 100179


It looks back to normal now.