Dossier /home/e-smith/Maildir/new archi plein

[mnttech]

Bonjour,

Ça faisait un petit moment que je venais ici pour lire les forums sans jamais poster.
Mais j'ai eu beau chercher je n'ai pas trouver de solution à mon problème.

J'ai récupéré il y a peu la maintenance d'un serveur mail sous sme server (il ne sert que de serveur mail) et la partition racine était pleine à 100%. Du coup certains services stoppaient et, en toute logique, le serveur ne faisait plus son boulot. J'ai donc été appelé pour voir ce qu'il se passait et je m'aperçois que les dossiers /home/e-smith/Maildir/new et cur sont la cause du problème.

Je supprime donc tous les fichiers du dossier cur. (environ 2Go)
Au passage un petit

Code: Tout sélectionner

ls | wc -l

me donne un truc comme 177000 fichiers donc autant vous dire que j'ai été obligé de passer par

Code: Tout sélectionner

ls | xargs rm

pour pouvoir supprimer tous les mails contenu dans le dossier. En fait le serveur mail sert pour plusieurs noms de domaine et il reçoit environ 5000 spam sur le compte admin en 24h (toutes les fausses adresses et toussa). On est à la limite du mailBomb constant.
Bref, je veux faire pareil pour le dossier new mais la commande

Code: Tout sélectionner

ls | xargs rm

me renvoi que la mémoire allouée est épuisée ou insuffisante (je ne me souviens plus exactement).
J'ai également tenté ma chance avec find mais le serveur fini par planter.

Alors je ne sais pas comment vider ce dossier qui doit contenir un paquet énorme de spam.
Une idée serait la bienvenue.
Merci d'avance.

[jdh]

En général on coupe la commande rm. Par exemple

rm a*
rm b*
rm 1*
...

(de préférence avec "rm -f" !)

[mnttech]

Merci mais malheureusement j'avais déjà tenté le coup.
Une autre idée?

EDIT : pour préciser le problème est le même qu'avec

Code: Tout sélectionner

rm *

j'obtiens : liste d'argument trop longue.

[jdh]

(C'est assez logique que "rm *" qui est remplacée par "rm fich1 .... fich177000" soit une instruction trop longue !)

Beh on continue : si diviser en 26 ne suffit pas, on divise en 26x26 ...

Je ne sais pas comment sont nommés les fichiers, mais, en en regardant la liste, on doit pouvoir trouver la façon de grouper en paquets tels que rm (paquets) ne soit pas trop long ...

Il est possible de jouer avec "seq" : par exemple "seq 1000 9999" retourne 1000 1001 ... 9999 : intéressant pour une boucle genre "for i in `seq 1000 9999`; do echo $i; rm -f ${i}*; done" !

[sibsib]

hello,

Aussi, parfois, si la commande 'ls' passe encore (pas garanti non plus), on peut faire un ls dans un fichier,
puis soit passer ce fichier dans une boucle for, soit découper ce fichier, plusieurs variantes sont possibles.

Si ls ne passe plus, il faut probablement passer à au autre langage que le shell (perl me semble-t-il ne devrait pas connaitre cette limite de nombre de fichiers).

Bonne chance,
Pascal

[mnttech]

@jdh Je ne peux pas regarder la liste de fichier. C'est justement mon problème. la commande 'ls' ne passe pas sur le dossier. Je l'ai précisé plus haut, elle me renvoit que la mémoire allouée est épuisée...
Mais peut-être que quelqu'un à une idée du nommage type des fichiers contenu dans ce dossier ce qui me permettrait de le tenter via une boucle for en fractionnant le rm en beaucoup de fois.

@sibsib La commande ls ne passe plus. Je vais tenter avec perl pour voir...

[fraedhrim]

Salut,

C'est étonnant que la commande "ls | rm" rale si "ls | wc -l" passe... Que "ls /blablabla/cur/*" ne passe pas OK mais un "ls /blablabla/cur" doit passer.

As-tu essayé ça ?

Code: Tout sélectionner

ls -1 /blablabla/cur | xargs -i rm /blablabla/cur/{}


Ca devrait lister les bazars un par un et pas en liste trop longue.

A+

F

[mnttech]

@fraedhrim Tu as mal lu. J'ai indiqué que le

Code: Tout sélectionner

ls | wc -l

passe dans le dossier cur. Et j'ai donc pu effacer tous les fichiers de ce dossier. Mais là ou je bloque c'est sur le dossier new ou le ls ne passe pas. Je ne teste donc pas ta commande car l'argument -1 ne va rien y changer.

Mais par contre j'ai trouver plusieurs pistes qui seront surement bonne mais que je n'arrive pas à mettre en œuvre via ssh car les commandes prennent trop de temps et le tunnel vpn de l'entreprise ne tient pas bien (je passe par un vpn pour accéder au serveur en ssh).
Je pense que quelqu'un a eu le même soucis que moi ici et je vais donc tester ces différentes méthodes directement sur place.

Je vous tiendrait au courant. Je pense essayer ça lundi.

[jdh]

Astuce : la commande "screen" : l'intérêt est de créer une session, de la détacher, de se déconnecter, puis se reconnecter et se rattacher à la session : idéal pour ne pas maintenir un vpn pendant un temps important tout en se gardant l'historique de la session qui tourne ...


Il doit bien exister un rpm pour SME ...

[mnttech]

Merci pour screen, je ne connaissais pas. Je vais regarder de ce coté là.
Surtout que si je met le serveur à genoux en supprimant tous ces fichiers, c'est mieux que je fasse ça le week-end quand personne n'utilise les mails.

[Gaston]

Bonsoir,
la structure du nom ressemble à : 1268746034.12837.smeserver
le premier chiffre est le timstamp unix si je ne m'abuse, tu peux donc trouver des regex adaptées
mais moi je tenterai un "

Code: Tout sélectionner

find /home/e-smith/Maildir/new -type f -exec rm -f {} \;

" je pense que cela traite les fichier un à un sans refaire une liste d'argument (contrairement à un find . -type f -print | xargs rm ) ou alors j'invers les deux
tu peux aussi ajouter une option de "-ctime" au find ...
bien sur attention de le lancer du répertoire où tu veux supprimer les fichiers bien sur , et pour t'en assurer, tu remplaces le 'rm -f' par un 'ls -l' et après tu avises

bon courage et +1 pour l'usage de screen

G.

[mnttech]

Merci à tous pour votre aide. J'ai réussi à m'en sortir avec la commande :

Code: Tout sélectionner

find /home/e-smith/Maildir/new -type f -exec rm -f {} \;

Enfin j'espère que j'ai réussi car la commande est en cours...
Mais j'ai tenté avec un ls -l avant et au bout d'un moment j'ai vu défilé les fameux spams.
Par contre je guettais la conso cpu et ram avec top et j'ai constaté que la conso RAM ne faisais que de monter. (20% avant que je kill la commande)
Je verrais bien ce qu'il se passe, je vais laisser tourner ça cette nuit.
Merci encore, vraiment sympa et connaisseurs les gens sur ce forum.

EDIT : Je viens de jeter un coup d'œil, j'avais rajouter -v à rm pour voir un peu ce qu'il ce passait et les fichiers sont effectivement en train d'être supprimer. Par contre le serveur est vraiment à genoux. (25% de cpu et 20% de ram mais visiblement ça reste stable)