La partition / est pleine à cause de la queue de Qmail
Attention: CE GUIDE CONCERNE UNIQUEMENT OVH RELEASE 1 ET OVH RELEASE 2 ! Ne pas appliquer sur un serveur plesk !
Gardez en mémoire que cette procédure vide totalement la queue de mail. Les messages qui y sont présent peuvent être perdus
Comment s'en rendre compte ?
Mails bloqués, certains services ne (re)démarrent plus (comme Apache).
Conséquences
Partition système pleine (cf.
SlashFull). La queue de mails est trop remplie, qmail n'arrive plus à la traîter.
Causes
Vous avez mal geré /etc/tcp.smtp et votre serveur a été utilisé pour un spam. Votre disque est plein. Il y a plein d'email dans le spool et vous n'avez qu'une solution : refaire la queue
Release 1
Attention ! Cette intervention est délicate et peut amener à ce que le serveur de mails ne fonctionne plus du tout !
Procéder ainsi en 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
Il faut donc effacer le repertoire et le refaire depuis le début. On arrete qmail avant :
# /etc/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
On respire.
Pour refaire la queue, on peut utiliser :
ftp://ftp.netmeridian.com/queue-fix.tar.gz
ou
http://pyropus.ca/software/queue-repair/queue-repair-0.9.0.tar.gz
Prenons par exemple qmail-repair. Nous commençons par récupérer et décompresser le soft :
[root@julien root]# mkdir /temp
[root@julien root]# cd /temp/
Avant toute chose, testons la manipulation dans le répertoire courant (pour recréer une queue de mails sans danger) :
[root@julien queue-repair-0.9.0]# ./queue_repair.py -c -s 23 --no-bigtodo .
Si tout se passe bien, vous pouvez vérifier que la queue a bien été recréée :
[root@julien queue-repair-0.9.0]# ls -l queue
total 36
drwx------ 2 qmails qmail 4096 mar 25 17:39 bounce
drwx------ 25 qmails qmail 4096 mar 25 17:39 info
drwx------ 2 qmailq qmail 4096 mar 25 17:39 intd
drwx------ 25 qmails qmail 4096 mar 25 17:39 local
drwxr-x--- 2 qmailq qmail 4096 mar 25 17:39 lock
drwxr-x--- 25 qmailq qmail 4096 mar 25 17:39 mess
drwx------ 2 qmailq qmail 4096 mar 25 17:39 pid
drwx------ 25 qmails qmail 4096 mar 25 17:39 remote
drwxr-x--- 2 qmailq qmail 4096 mar 25 17:39 todo
On peut maintenant passer aux choses sérieuses, c'est-à-dire recréer la queue de mails réellement utilisée par le serveur de mails puis vérifier que tout est bien là :
[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/
Il reste maintenant à redémarrer qmail (ne pas oublier de passer en / pour redémarrer qmail)
# cd /
# /etc/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
Visiblement tout est redevenu normal.
Release 2
| server ~ # df -h |
| Sys. de fich. | Tail. | Occ. | Disp. | %Occ. | Monté sur |
| /dev/md/1 | 2,9G | 2,9G | 0 | 100% | / |
| /dev/md/2 | 144G | 334M | 136G | 1% | /home |
| shm | 497M | 0 | 497M | 0% | /dev/shm |
| server ~ # du -sh /var/qmail/queue/ |
| 928M /var/qmail/queue/ |
| server ~ # /var/qmail/bin/qmail-qstat |
| messages in queue: 124001 |
| messages in queue but not yet preprocessed: 3117 |
| server ~ # |
Ce serveur est saturé, la queue de mail fait 928M et semble saturée. Nous arrêtons les services :
| server ~ # /etc/init.d/clamd stop |
| * Stopping clamd ... |
| * Failed to stop clamd | [ !! ] |
| * Stopping freshclam ... | [ ok ] |
| server ~ # /etc/init.d/spamd stop |
| * Stopping spamd ... | [ ok ] |
| server ~ # /etc/init.d/qmail stop |
| * Stopping Qmail ... | [ ok ] |
| server ~ # |
Avant toute action, il faut vérifier que le multilog n'est plus en action. Lorsque la commande suivante ne vous envoie plus de ligne contenant '/usr/local/bin/multilog' vous pouvez passer à la suite.
server ~ # ps aux | grep multi
qmaill 5865 0.0 0.0 1344 284 pts/0 S 16:30 0:00 /usr/local/bin/multilog /var/log/qmail/
qmaill 5872 0.0 0.0 1344 284 pts/0 S 16:30 0:00 /usr/local/bin/multilog /var/log/qmailpop3/
qmaill 5876 0.0 0.0 1344 284 pts/0 S 16:30 0:00 /usr/local/bin/multilog /var/log/qmailsmtp/
root 9316 0.0 0.0 1860 716 pts/0 R+ 17:14 0:00 grep --colour=auto multi
server ~ #
Par mesure de sécurité, nous allons copier la queue de mail plutôt que de la supprimer. Une récupération pourra ainsi être envisagée par la suite.
| server ~ # mkdir /home/backup |
| server ~ # mv /var/qmail/queue/ /home/backup/queue_mail_20081114 |
| server ~ # df -h |
| Sys. de fich. | Tail. | Occ. | Disp. | %Occ. | Monté sur |
| /dev/md/1 | 2,9G | 2,0G | 928M | 65% | / |
| /dev/md/2 | 144G | 1,3G | 135G | 1% | /home |
| shm | 497M | 0 | 497M | 0% | /dev/shm |
| server ~ # |
Le serveur a récupéré des ressources, il est temps de réparer la queue de mail.
server ~ # mkdir /temp
server ~ # cd /temp/
server temp # wget http://pyropus.ca/software/queue-repair/queue-repair-0.9.0.tar.gz
server temp # tar -xvzf queue-repair-0.9.0.tar.gz
server temp # cd queue-repair-0.9.0
server queue-repair-0.9.0 # ./queue_repair.py -c -s 23 --no-bigtodo /var/qmail
server queue-repair-0.9.0 # ls -l /var/qmail/
total 32
drwxr-sr-x 2 alias qmail 4096 jun 2 2006 alias
drwxr-xr-x 2 root qmail 4096 nov 14 15:04 bin
drwxr-xr-x 2 root qmail 4096 jun 2 2006 boot
drwxr-xr-x 2 root qmail 4096 nov 14 15:04 control
drwxr-xr-x 3 root qmail 4096 jun 2 2006 doc
drwxr-xr-x 10 root qmail 4096 jun 2 2006 man
drwxr-x--- 11 qmailq qmail 4096 nov 14 16:26 queue
drwxr-xr-x 2 root qmail 4096 nov 14 15:04 users
Il nous reste alors à relancer les service dans l'ordre :
| server queue-repair-0.9.0 # /etc/init.d/qmail start |
| * Starting Qmail ... | [ ok ] |
| * Starting Pop ... | [ ok ] |
| * Starting Smtp ... | [ ok ] |
| server queue-repair-0.9.0 # /etc/init.d/clamd start |
| * Starting clamd ... | [ ok ] |
| * Starting freshclam ... | [ ok ] |
| server queue-repair-0.9.0 # /etc/init.d/spamd start |
| * Starting spamd ... | [ ok ]
|
Vous pouvez refaire un test d'envoi de mail, celui ci devrait afficher ce type d'informations dans vos logs :
server queue-repair-0.9.0 # tail -f /var/log/qmail/current
@40000000491d93771c6c4c6c status: exiting
@40000000491d998a13d2554c status: local 0/10 remote 0/20
@40000000491d99f434a30384 new msg 69683
@40000000491d99f434a30b54 info msg 69683: bytes 226 from qp 6113 uid 0
@40000000491d99f435109a34 starting delivery 1: msg 69683 to remote user@domain.tld
@40000000491d99f43510a204 status: local 0/10 remote 1/20
@40000000491d99f501c68d3c delivery 1: success: 213.186.33.73_accepted_message./Remote_host_said:_250_ok_1226676713_qp_19643/
@40000000491d99f501c6950c status: local 0/10 remote 0/20
@40000000491d99f501c698f4 end msg 69683