Checker si un montage est vraiment bien opérationnel
27 réponses
Francois Lafont
Bonjour à tous,
Connaissez-vous le moyen le plus fiable possible pour tester si
un montage est bien monté (si j'ose dire) et parfaitement
opérationnel.
Au départ, je pensais par exemple tester la présence d'un fichier
à la racine de chaque répertoire faisant office de point de montage.
Mais le souci c'est que je veux mettre en place un tel check dans
le cadre d'une supervision sur un certain nombre de machines (environ
60) et cela suppose qu'il faut se mettre d'accord sur un fichier à
tester sur chaque montage ce qui n'est pas forcément simple car celui
dépendra du montage en question. Du coup c'est un peu pénible à mettre
en place « en masse » car pas super générique.
Autre idée : j'ai pensé à la commande mountpoint qui nous dit si un
répertoire est un point de montage ou non. Mais le souci c'est que ce
n'est pas une vérification assez « forte » pour moi. En effet, je crois
bien que par exemple sur un partage NFS monté on peut parfaitement
avoir la commande mountpoint qui nous dit que tel répertoire est bien
un point de montage mais si le serveur NFS est en vrac et que le partage
est inaccessible la commande mountpoint ne le verra pas (elle se contentera
de nous dire que le répertoire est bien un point de montage sans se
soucier de savoir si ce qu'il y a dedans est accessible ou non).
Bref, je cherche un moyen de checker qu'un montage est « 100% OK » et si
possible de manière un peu générique. Est-ce possible d'après ? Le test
de la présence d'un fichier à la racine du montage est-il le seul
moyen 100% fiable ?
for file in *; do ...; done et qu'on fait un exit à la fin du premier tour ?
Par exemple :
:~/mik-f-stockz$ for file in *; do echo $file;break; done mik-f-stockz100.mn :~/mik-f-stockz$
Ultra rapide testé avec 200000 fichiers
Au fait si un répertoire contient trop de fichier, si on utilise find . on s'en sort mieux :)
-- Michaël
Francois Lafont
Le 08/09/2013 19:13, Nicolas George a écrit :
Non, quand un programme ne fait rien avec un signal, ils ont leur action par défaut, qui dépend du signal. C'est documenté dans signal(7). On voit en particulier que l'action par défaut pour SIGPIPE est de terminer le processus. Il n'y a pas beaucoup de signaux qui sont ignorés par défaut.
Ok, donc si je lance un programme dont l'implémentation ne gère aucun signal dans son code, si j'envoie au processus un SIGPIPE ou un SIGHUP (par exemple), en principe le résultat sera le même (a priori l'arrêt du programme).
Tu confondais probablement avec le fait que SIGKILL et SIGSTOP sont spéciaux en ce qu'un programme ne peut ni les ignorer ni les rattraper ni les bloquer.
Ah oui, c'est exactement ça, merci beaucoup. Tout est plus clair maintenant.
-- François Lafont
Le 08/09/2013 19:13, Nicolas George a écrit :
Non, quand un programme ne fait rien avec un signal, ils ont leur action par
défaut, qui dépend du signal. C'est documenté dans signal(7). On voit en
particulier que l'action par défaut pour SIGPIPE est de terminer le
processus. Il n'y a pas beaucoup de signaux qui sont ignorés par défaut.
Ok, donc si je lance un programme dont l'implémentation ne gère aucun
signal dans son code, si j'envoie au processus un SIGPIPE ou un
SIGHUP (par exemple), en principe le résultat sera le même (a priori
l'arrêt du programme).
Tu confondais probablement avec le fait que SIGKILL et SIGSTOP sont spéciaux
en ce qu'un programme ne peut ni les ignorer ni les rattraper ni les
bloquer.
Ah oui, c'est exactement ça, merci beaucoup. Tout est plus clair maintenant.
Non, quand un programme ne fait rien avec un signal, ils ont leur action par défaut, qui dépend du signal. C'est documenté dans signal(7). On voit en particulier que l'action par défaut pour SIGPIPE est de terminer le processus. Il n'y a pas beaucoup de signaux qui sont ignorés par défaut.
Ok, donc si je lance un programme dont l'implémentation ne gère aucun signal dans son code, si j'envoie au processus un SIGPIPE ou un SIGHUP (par exemple), en principe le résultat sera le même (a priori l'arrêt du programme).
Tu confondais probablement avec le fait que SIGKILL et SIGSTOP sont spéciaux en ce qu'un programme ne peut ni les ignorer ni les rattraper ni les bloquer.
Ah oui, c'est exactement ça, merci beaucoup. Tout est plus clair maintenant.
-- François Lafont
Nicolas George
Michaël Nourry, dans le message , a écrit :
:~/mik-f-stockz$ for file in *; do echo $file;break; done mik-f-stockz100.mn
Le shell lit tout le répertoire au moment de développer « * ».
Michaël Nourry, dans le message <522ccfa4@ac-versailles.fr>, a écrit :
mickey@sauvAge:~/mik-f-stockz$ for file in *; do echo $file;break; done
mik-f-stockz100.mn
Le shell lit tout le répertoire au moment de développer « * ».
:~/mik-f-stockz$ for file in *; do echo $file;break; done mik-f-stockz100.mn
Le shell lit tout le répertoire au moment de développer « * ».
Francois Lafont
Le 08/09/2013 21:27, Michaël Nourry a écrit :
Et si on fait un truc du genre :
for file in *; do ...; done et qu'on fait un exit à la fin du premier tour ?
En fait, je pense que c'est moins bien que le « ls -f | head » car avec le *, je pense (sans en être sûr car j'ignore comment tout cela est implémenté) que le shell va vouloir le développer en la liste de tous les fichiers (qui ne commencent pas par un ".") du répertoire courant avant même de commencer la boucle et du coup il va quand même lister plus ou moins tous les fichiers du répertoire chose que l'on veut éviter.
Suite aux remarques de Nicolas (que je ne fais que synthétiser), on s'aperçoit qu'avec l'instruction « ls -f | head » le programme head va se terminer une fois qu'il aura mangé ses 10 lignes en entrée et que du coup le pipe sera cassé, ce qui entraînera de la part du noyau l'envoi du signal SIGPIPE (« broken pipe ») au processus "ls" ce qui va provoquer l'arrêt de la commande "ls" (qui manifestement ne cherche pas à attraper ce signal pour en faire je ne sais quoi et suit donc le comportement par défaut induit par SIGPIPE). Du coup, notre "ls" ne cherchera pas à lire trop d'entrées dans notre répertoire et tout va bien. :-)
-- François Lafont
Le 08/09/2013 21:27, Michaël Nourry a écrit :
Et si on fait un truc du genre :
for file in *; do ...; done
et qu'on fait un exit à la fin du premier tour ?
En fait, je pense que c'est moins bien que le « ls -f | head »
car avec le *, je pense (sans en être sûr car j'ignore comment
tout cela est implémenté) que le shell va vouloir le développer
en la liste de tous les fichiers (qui ne commencent pas par un
".") du répertoire courant avant même de commencer la boucle et
du coup il va quand même lister plus ou moins tous les fichiers
du répertoire chose que l'on veut éviter.
Suite aux remarques de Nicolas (que je ne fais que synthétiser),
on s'aperçoit qu'avec l'instruction « ls -f | head » le programme
head va se terminer une fois qu'il aura mangé ses 10 lignes en entrée
et que du coup le pipe sera cassé, ce qui entraînera de la part du noyau
l'envoi du signal SIGPIPE (« broken pipe ») au processus "ls" ce qui
va provoquer l'arrêt de la commande "ls" (qui manifestement ne cherche
pas à attraper ce signal pour en faire je ne sais quoi et suit donc
le comportement par défaut induit par SIGPIPE). Du coup, notre "ls" ne
cherchera pas à lire trop d'entrées dans notre répertoire et tout
va bien. :-)
for file in *; do ...; done et qu'on fait un exit à la fin du premier tour ?
En fait, je pense que c'est moins bien que le « ls -f | head » car avec le *, je pense (sans en être sûr car j'ignore comment tout cela est implémenté) que le shell va vouloir le développer en la liste de tous les fichiers (qui ne commencent pas par un ".") du répertoire courant avant même de commencer la boucle et du coup il va quand même lister plus ou moins tous les fichiers du répertoire chose que l'on veut éviter.
Suite aux remarques de Nicolas (que je ne fais que synthétiser), on s'aperçoit qu'avec l'instruction « ls -f | head » le programme head va se terminer une fois qu'il aura mangé ses 10 lignes en entrée et que du coup le pipe sera cassé, ce qui entraînera de la part du noyau l'envoi du signal SIGPIPE (« broken pipe ») au processus "ls" ce qui va provoquer l'arrêt de la commande "ls" (qui manifestement ne cherche pas à attraper ce signal pour en faire je ne sais quoi et suit donc le comportement par défaut induit par SIGPIPE). Du coup, notre "ls" ne cherchera pas à lire trop d'entrées dans notre répertoire et tout va bien. :-)
-- François Lafont
Francois Lafont
Bonsoir,
Le 08/09/2013 17:40, Francois Lafont a écrit :
if timeout --signal=SIGKILL "$TIMEOUT" mountpoint "$dir" >/dev/null 2>&1 && timeout --signal=SIGKILL "$TIMEOUT" ls -f "$dir" | head -n 5 >/dev/null 2>&1 then echo "$dir:ok" else echo "$dir:problem" fi
Il y a quand même un truc qui me chagrine dans le if ci-dessus, en particulier dans la deuxième commande timeout. C'est peu probable que ça arrive mais si jamais la commande « ls -f "$dir" » se plante *avant* le timeout (je ne vois pas pourquoi étant donné qu'avant on a testé que le répertoire est bien un point de montage et donc que le répertoire existe forcément mais bon...) alors la commande renverra quand même 0 et le test sera Ok. En effet, manifestement, dans :
ls -f "$dir" | head -n 5
la valeur de retour de l'instruction est celle de head et donc c'est celle qui est prise en compte dans le if. Du coup c'est un peu dommage et je crois que je vais m'en ternir à ça :
if timeout --signal=SIGKILL "$TIMEOUT" mountpoint "$dir" >/dev/null 2>&1 && timeout --signal=SIGKILL "$TIMEOUT" ls -f "$dir" >/dev/null 2>&1 then echo "$dir:ok" else echo "$dir:problem" fi
sans le head donc. Tant pis pour l'optimisation. De toute façon, si on se retrouve avec un partage nfs avec des tonnes de fichiers à la racine, c'est qu'il y a un souci et il faut le résoudre.
-- François Lafont
Bonsoir,
Le 08/09/2013 17:40, Francois Lafont a écrit :
if timeout --signal=SIGKILL "$TIMEOUT" mountpoint "$dir" >/dev/null 2>&1 &&
timeout --signal=SIGKILL "$TIMEOUT" ls -f "$dir" | head -n 5 >/dev/null 2>&1
then
echo "$dir:ok"
else
echo "$dir:problem"
fi
Il y a quand même un truc qui me chagrine dans le if ci-dessus, en
particulier dans la deuxième commande timeout. C'est peu probable
que ça arrive mais si jamais la commande « ls -f "$dir" » se plante
*avant* le timeout (je ne vois pas pourquoi étant donné qu'avant on a
testé que le répertoire est bien un point de montage et donc que le
répertoire existe forcément mais bon...) alors la commande renverra
quand même 0 et le test sera Ok. En effet, manifestement, dans :
ls -f "$dir" | head -n 5
la valeur de retour de l'instruction est celle de head et donc c'est
celle qui est prise en compte dans le if. Du coup c'est un peu dommage
et je crois que je vais m'en ternir à ça :
if timeout --signal=SIGKILL "$TIMEOUT" mountpoint "$dir" >/dev/null 2>&1 &&
timeout --signal=SIGKILL "$TIMEOUT" ls -f "$dir" >/dev/null 2>&1
then
echo "$dir:ok"
else
echo "$dir:problem"
fi
sans le head donc. Tant pis pour l'optimisation. De toute façon, si on se
retrouve avec un partage nfs avec des tonnes de fichiers à la racine,
c'est qu'il y a un souci et il faut le résoudre.
if timeout --signal=SIGKILL "$TIMEOUT" mountpoint "$dir" >/dev/null 2>&1 && timeout --signal=SIGKILL "$TIMEOUT" ls -f "$dir" | head -n 5 >/dev/null 2>&1 then echo "$dir:ok" else echo "$dir:problem" fi
Il y a quand même un truc qui me chagrine dans le if ci-dessus, en particulier dans la deuxième commande timeout. C'est peu probable que ça arrive mais si jamais la commande « ls -f "$dir" » se plante *avant* le timeout (je ne vois pas pourquoi étant donné qu'avant on a testé que le répertoire est bien un point de montage et donc que le répertoire existe forcément mais bon...) alors la commande renverra quand même 0 et le test sera Ok. En effet, manifestement, dans :
ls -f "$dir" | head -n 5
la valeur de retour de l'instruction est celle de head et donc c'est celle qui est prise en compte dans le if. Du coup c'est un peu dommage et je crois que je vais m'en ternir à ça :
if timeout --signal=SIGKILL "$TIMEOUT" mountpoint "$dir" >/dev/null 2>&1 && timeout --signal=SIGKILL "$TIMEOUT" ls -f "$dir" >/dev/null 2>&1 then echo "$dir:ok" else echo "$dir:problem" fi
sans le head donc. Tant pis pour l'optimisation. De toute façon, si on se retrouve avec un partage nfs avec des tonnes de fichiers à la racine, c'est qu'il y a un souci et il faut le résoudre.
-- François Lafont
Francois Lafont
Bonjour,
Le 10/09/2013 00:32, Francois Lafont a écrit :
ls -f "$dir" | head -n 5
la valeur de retour de l'instruction est celle de head et donc c'est celle qui est prise en compte dans le if (pas celle de la commande ls).
Sur ce point là, j'ai trouvé un truc mais ça ne marche que sous Bash. Avec :
(command | head && exit $PIPESTATUS)
Le "exit" code sera celui de la commande "command" et non celui de la commande "head". Malheureusement, je n'ai pas trouvé d'équivalent en Shell « Posix ».
-- François Lafont
Bonjour,
Le 10/09/2013 00:32, Francois Lafont a écrit :
ls -f "$dir" | head -n 5
la valeur de retour de l'instruction est celle de head et donc c'est
celle qui est prise en compte dans le if (pas celle de la commande ls).
Sur ce point là, j'ai trouvé un truc mais ça ne marche que sous Bash. Avec :
(command | head && exit $PIPESTATUS)
Le "exit" code sera celui de la commande "command" et non celui de la
commande "head". Malheureusement, je n'ai pas trouvé d'équivalent en
Shell « Posix ».
la valeur de retour de l'instruction est celle de head et donc c'est celle qui est prise en compte dans le if (pas celle de la commande ls).
Sur ce point là, j'ai trouvé un truc mais ça ne marche que sous Bash. Avec :
(command | head && exit $PIPESTATUS)
Le "exit" code sera celui de la commande "command" et non celui de la commande "head". Malheureusement, je n'ai pas trouvé d'équivalent en Shell « Posix ».
