Problème commande find

Version imprimable

13/04/2015, 12h45
alien6390

Problème commande find

Bonjour à tous,

Dans le cadre d'un projet de virtualisation, j'ai mis en place un script permettant d'effectuer des backups de machines virtuelles. Ce script se situe sur un ESXi 4.1.0.
Les machines virtuelles sont sauvegardées dans un dossier NFS sur le réseau. Une commande à la fin du script permet de vérifier la présence de dossiers de sauvegarde plus vieux de 6 jours et de les éliminer. Chaque jours la commande devrait trouver 3 dossiers à éliminer (3 versions de backup de 3 machines virtuelles).
Malheureusement, cette commande fonctionne à moitié: exécutée, elle trouve le premier "vieux" dossier, l'élimine et s'arrête là! Je me retrouve donc chaque fois avec 2 versions de backup plus vieux de 6 jours et cela ne fait qu'augmenter avec le temps.
J'espère m'être bien expliqué.
Voici la commande présente dans le script:

Code:

find $DESTINATION_BACKUP -type d -mtime +6 -exec rm -rf {} \;

Je vous remercie d'avance de votre aide.
13/04/2015, 15h50
Sve@r

Bonjour

As-tu lu dans le man de find que le -mtime (ainsi que les -atime et -ctime) fonctionnent en journées entières et que toute partie fractionnaire est ignorée ??? Ainsi un fichier modifié il y a 6 jours et 23h sera vu comme ayant été modifié il y a 6 jours pile et donc ne rentrera pas dans la catégorie "strictement supérieure à 6 jours"...
Solution: mettre un -mtime +5, ou essayer avec un -mmin +8640...

Accessoirement tu peux remplacer le "\;" par un "+". La différence c'est qu'avec le point-virgule, la commande placée après le -exec est exécutée pour chaque fichier trouvé, alors qu'avec un "plus" les fichiers sont mémorisés dans une liste interne qui est ensuite passée en une fois à la commande laquelle n'est alors appelée qu'une seule fois (gain de temps). Mais ce n'est possible que pour les commandes pouvant accepter plusieurs fichiers d'un coup (ce qui est le cas de rm)...
13/04/2015, 15h59
alien6390

Merci pour cette réponse mais la partie fractionnaire ignorée ne me pose pas de problèmes.
Cela me dérange pas d'avoir des backups vieux de 6 jours et 23 heures.
Par contre il y a toujours la présence de backups vieux de 8 à 12 jours, vu que la commande lancée efface à chaque fois (backup lancé tous les soirs) 1 dossier vieux sur 3 en total.
13/04/2015, 16h05
Sve@r

Dans ce cas il te faut remplacer le -exec par un -print pour que tu vérifies si les fichiers "trouvables" sont réellement "trouvés"...
Et si c'est le cas (ça m'étonnerait d'ailleurs que cela ne le soit pas de la part d'une commande déployée sur des milliers d'Unix/Linux et dont la fiabilité est reconnue...), alors vérifier les droits des dossiers qui les contiennent. En effet, si t'as pas le droit d'écriture sur un dossier, tu ne pourras pas effacer les fichiers qui s'y trouvent ; cette règle s'appliquant, dans le cas du "-r", à tous les dossiers situés sous le dossier ciblé par le rm. Surtout que dans ton cas il s'agit d'un dossier NFS donc possédant d'éventuelles règles de gestion en ce qui concerne les uid des hosts distants qui tentent d'y accéder (surtout si cet uid est celui de root !!!)

J'ai testé avec la commande -print et tous les dossiers destinés à être effacés sont correctement listés. Ensuite au niveau des droits, tout est OK.
Apparemment, le problème se situe au niveau de la commande rm. En ajoutant le paramètre "-maxdepth 1" (pas besoin d'aller chercher plus loin dans le dossier), une erreur m'est retournée mais je ne saisi pas le sens:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
/vmfs/volumes/c4c4b524-531083fa/test # find -type d -maxdepth 1 -mtime +6 -exec rm -rf {} \;
find: ./Citron2015-03-30: No such file or directory
rm: invalid option --
BusyBox v1.9.1-VMware-visor-klnext-8021 (2011-10-21 17:03:36 PDT) multi-call binary
 
Usage: rm [OPTION]... FILE...
 
Remove (unlink) the FILE(s). You may use '--' to
indicate that all following arguments are non-options.
 
Options:
        -i      Always prompt before removing each destination
        -f      Remove existing destinations, never prompt
        -r,-R   Remove the contents of directories recursively
 
rm: invalid option -- u
BusyBox v1.9.1-VMware-visor-klnext-8021 (2011-10-21 17:03:36 PDT) multi-call binary
 
Usage: rm [OPTION]... FILE...
 
Remove (unlink) the FILE(s). You may use '--' to
indicate that all following arguments are non-options.
 
Options:
        -i      Always prompt before removing each destination
        -f      Remove existing destinations, never prompt
        -r,-R   Remove the contents of directories recursively
 
rm: invalid option -- 3
BusyBox v1.9.1-VMware-visor-klnext-8021 (2011-10-21 17:03:36 PDT) multi-call binary
 
Usage: rm [OPTION]... FILE...
 
Remove (unlink) the FILE(s). You may use '--' to
indicate that all following arguments are non-options.
 
Options:
        -i      Always prompt before removing each destination
        -f      Remove existing destinations, never prompt
        -r,-R   Remove the contents of directories recursively

J'observe bien qu'il élimine le premier dossier (find: ./Citron2015-03-30: No such file or directory) mais après me retourne une erreur.
Merci de ta patience.

13/04/2015, 16h40
Flodelarab

Bonjour,

as-tu des noms de dossier avec des espaces ? "./Citron2015-03-30 et les heures" par exemple ?
13/04/2015, 16h44
alien6390

1 pièce(s) jointe(s)

Citation:

Envoyé par Flodelarab

Bonjour,

as-tu des noms de dossier avec des espaces ? "./Citron2015-03-30 et les heures" par exemple ?

Hello,
Non aucun, j'ai bien pris la précaution:
Pièce jointe 174657
13/04/2015, 16h57
Flodelarab

Cette liste est intéressante. Elle présente des dossiers présents 2 fois. La première il supprime le dossier, la seconde fois, il plante. Comment ton dossier -maxdepth 1 peut-il avoir deux sous-dossiers du même nom ?
13/04/2015, 17h01
alien6390

Je ne vois pas de dossiers du même nom...
Peut-être confonds-tu Citron et Cuivre?
13/04/2015, 17h07
alien6390
Citation:

Envoyé par Sve@r

Accessoirement tu peux remplacer le "\;" par un "+". La différence c'est qu'avec le point-virgule, la commande placée après le -exec est exécutée pour chaque fichier trouvé, alors qu'avec un "plus" les fichiers sont mémorisés dans une liste interne qui est ensuite passée en une fois à la commande laquelle n'est alors appelée qu'une seule fois (gain de temps). Mais ce n'est possible que pour les commandes pouvant accepter plusieurs fichiers d'un coup (ce qui est le cas de rm)...

J'ai essayé mais voici ce qui me retourne:
Code:

1 2 3 /vmfs/volumes/c4c4b524-531083fa/test # find -type d -mtime +6 -exec rm -rf {} + find: -exec CMD must end by ';'
13/04/2015, 17h24
Flodelarab

Au temps pour moi... Les dossiers sont différents. Pour le pavé de messages d'erreur, c'est clair: find veut exécuter une commande sur un dossier qui n'existe pas ou plus, donc erreur. Du coup, rm n'a pas de cible, donc erreur de rm. Par contre il parle d'un "u" et un "3" dans le nom de dossier. A quoi cela peut-il correspondre?

Pour le point virgule, il termine la commande dans -exec. \; pour ne pas confondre avec ; qui termine la commande find.

Citation:

Envoyé par alien6390

Ensuite au niveau des droits, tout est OK.

Malgré le fait que tu sois sur un dossier NFS ? A ce propos, qui est l'user qui travaille ??? Parce que si c'est root, il y a fort à parier que sur le dossier NFS il soit vu comme "anon" (uid 65535). En effet, généralement un admin qui implémente NFS n'aime pas voir le root distant traficoter ses dossiers locaux et programme alors le NFS pour qu'un root distant ses privilèges en arrivant sur sa machine. Tu peux le vérifier en tapant "mkdir dossier_distant/truc" et en regardant à qui appartient le dossier "truc"...

Accessoirement pour lever le doute à ce sujet tu peux essayer de recréer une arborescence identique sur ton propre host avec la commande suivante: mkdir /tmp/test; (cd dossier_distant; tar cf - .) | (cd /tmp/test; tar xpvf -). Ensuite en retestant ton find en local tu verras bien si les dossiers sont effacés (te faudra juste changer les critères du find car le mtime sera celui de la date de recopie).
Citation:
Envoyé par alien6390
une erreur m'est retournée mais je ne saisi pas le sens:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 /vmfs/volumes/c4c4b524-531083fa/test # find -type d -maxdepth 1 -mtime +6 -exec rm -rf {} \; find: ./Citron2015-03-30: No such file or directory rm: invalid option -- BusyBox v1.9.1-VMware-visor-klnext-8021 (2011-10-21 17:03:36 PDT) multi-call binary Usage: rm [OPTION]... FILE... Remove (unlink) the FILE(s). You may use '--' to indicate that all following arguments are non-options. Options: -i Always prompt before removing each destination -f Remove existing destinations, never prompt -r,-R Remove the contents of directories recursively rm: invalid option -- u BusyBox v1.9.1-VMware-visor-klnext-8021 (2011-10-21 17:03:36 PDT) multi-call binary Usage: rm [OPTION]... FILE... Remove (unlink) the FILE(s). You may use '--' to indicate that all following arguments are non-options. Options: -i Always prompt before removing each destination -f Remove existing destinations, never prompt -r,-R Remove the contents of directories recursively rm: invalid option -- 3 BusyBox v1.9.1-VMware-visor-klnext-8021 (2011-10-21 17:03:36 PDT) multi-call binary Usage: rm [OPTION]... FILE... Remove (unlink) the FILE(s). You may use '--' to indicate that all following arguments are non-options. Options: -i Always prompt before removing each destination -f Remove existing destinations, never prompt -r,-R Remove the contents of directories recursively
Bizarre. On dirait qu'il a pris le "-30" situé dans le nom comme une option "-3" passée au rm. Et le "-u" mentionné pourrait être le "u" de "unicode". Presque je serais enclin à penser que le dossier distant est situé sur un Windows (NFS implémenté par SAMBA) et que le retour du find renvoie des noms avec des caractères transformés par le protocole et donc ensuite rm perd ses billes.
On peut essayer de vérifier ça tapant find -type d -maxdepth 1 -mtime +6 -exec ls -l {} + 1>/tmp/log puis en allant regarder via vi le fichier "/tmp/log". S'il y a des caractères bizarres, vi les montrera...
Citation:
Envoyé par alien6390
J'ai essayé mais voici ce qui me retourne:
Code:

1 2 3 /vmfs/volumes/c4c4b524-531083fa/test # find -type d -mtime +6 -exec rm -rf {} + find: -exec CMD must end by ';'
Ca veut dire que tu n'utilises pas une version de find qui accepte cette syntaxe. Tu peux le voir en tapant find --version (la mienne affiche "find (GNU findutils) 4.4.2"). Tu travailles donc peut-être sur un OS un peu "exotique" (free bsd, openbsd, etc...) ?

Autre test possible: rm -rf $(find -maxdepth 1 -mtime +6 -print). Un peu "sale" (surtout si le find renvoie des noms avec espace) mais ça pourra remonter d'autres infos...

13/04/2015, 19h19
disedorgue

Bonjour,

Je pense que le problème est sur le fait que la variable $DESTINATION_BACKUP est vide, on obtient donc une syntaxe find pas conforme...:aie:
13/04/2015, 19h38
Sve@r

Non, désolé de te contredire car c'est bien vu mais dans ce cas ça fonctionne.
S'il était écrit find "$DESTINATION_BACKUP" ... alors oui avec une variable vide (ou inexistante) le find râlerait tout ce qu'il peut mais tel que c'est écrit (sans guillemets), alors si la variable est vide le find n'ayant pas de paramètre associé au dossier de départ recherche à partir de "." par défaut.
En revanche, si la variable contient un nom de dossier avec espace, là ça peut poser soucis car dans ce cas find ira chercher dans deux dossiers inexistants. Dans ce cas il serait nécessaire d'encadrer le nom de la variable de guillemets.

Mais ça me fait penser qu'il serait judicieux de rajouter set -x en début de script. Ainsi on aura plus en détail sur ce que les commandes impliquées voient, comprennent et ne comprennent pas...
13/04/2015, 21h34
disedorgue

Il n'y a pas de quoi être désolé, il est vrai que je me suis complètement trompé :oops:

Sinon, il serait aussi intéressant d'avoir une vision des potentiels fichiers cachés, ainsi que les options du montage nfs.
14/04/2015, 09h45
alien6390

Trouvé!
Le find n'est pas proprement géré sur ce shell et pose des problèmes avec l'utilisation du paramètre -exec.
Voici la solution qui marche à merveille (j'en remercie une connaissance :D):

Code:

find $DESTINATION_BACKUP -type d -mtime +6 | xargs rm –rf

Je vous remercie tous pour votre aide