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 ?
Le 08-09-2013, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité (auquel cas ça me va car je sais alors que la commande ls ne pompera pas trop de ressources réseaux quel que soit le répertoire en face) ou bien ls continue-t-il son travail dans le vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se situe pas au niveau réseau puisque le ls va à son terme) ?
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les deux commandes peuvent savoir où vont et/ou d'où viennent les données.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 08-09-2013, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
En fait, la question que je me pose, c'est est-ce que le « | head »
interrompt vraiment le travail de la commande ls une fois qu'il a son
nombre de lignes souhaité (auquel cas ça me va car je sais alors que
la commande ls ne pompera pas trop de ressources réseaux quel que soit
le répertoire en face) ou bien ls continue-t-il son travail dans le
vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se
situe pas au niveau réseau puisque le ls va à son terme) ?
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la
sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les
deux commandes peuvent savoir où vont et/ou d'où viennent les données.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 08-09-2013, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité (auquel cas ça me va car je sais alors que la commande ls ne pompera pas trop de ressources réseaux quel que soit le répertoire en face) ou bien ls continue-t-il son travail dans le vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se situe pas au niveau réseau puisque le ls va à son terme) ?
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les deux commandes peuvent savoir où vont et/ou d'où viennent les données.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Erwan David
Francois Lafont écrivait :
Salut Michaël, :-)
Le 07/09/2013 23:59, Michaël Nourry a écrit :
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Le souci c'est que ça me gêne un peu que le check modifie le système de fichiers (via une écriture), j'aimerais vraiment éviter d'y toucher.
Du coup, par rapport au "ls -f", je me suis dis que je pouvais le piper avec head afin d'écourter le travail de la commande ls. J'ai l'impression que ça marche. Sur des VMs, j'ai créé un partage nfs avec 100 000 fichiers dedans et j'ai tenté ceci :
N'oublie pas de dire à ls de ne pas trier les fichiers, sinon tu ne gagne rien.
Erf, oui tu as raison d'avoir peur :)
Et si au lieu de faire un ls, on fait par exemple un
echo date > fichier.temoin
(si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Le souci c'est que ça me gêne un peu que le check modifie le
système de fichiers (via une écriture), j'aimerais vraiment
éviter d'y toucher.
Du coup, par rapport au "ls -f", je me suis dis que je pouvais
le piper avec head afin d'écourter le travail de la commande ls.
J'ai l'impression que ça marche. Sur des VMs, j'ai créé un partage
nfs avec 100 000 fichiers dedans et j'ai tenté ceci :
N'oublie pas de dire à ls de ne pas trier les fichiers, sinon tu ne
gagne rien.
Erf, oui tu as raison d'avoir peur :) Et si au lieu de faire un ls, on fait par exemple un echo date > fichier.temoin (si pas d'erreur ça doit être bon)
Après pour être sûr on peut vérifier le contenu du fichier ...
Le souci c'est que ça me gêne un peu que le check modifie le système de fichiers (via une écriture), j'aimerais vraiment éviter d'y toucher.
Du coup, par rapport au "ls -f", je me suis dis que je pouvais le piper avec head afin d'écourter le travail de la commande ls. J'ai l'impression que ça marche. Sur des VMs, j'ai créé un partage nfs avec 100 000 fichiers dedans et j'ai tenté ceci :
N'oublie pas de dire à ls de ne pas trier les fichiers, sinon tu ne gagne rien.
-- Les simplifications c'est trop compliqué
Doug713705
Le 08-09-2013, Doug713705 nous expliquait dans fr.comp.os.linux.configuration :
Le 08-09-2013, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité (auquel cas ça me va car je sais alors que la commande ls ne pompera pas trop de ressources réseaux quel que soit le répertoire en face) ou bien ls continue-t-il son travail dans le vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se situe pas au niveau réseau puisque le ls va à son terme) ?
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les deux commandes peuvent savoir où vont et/ou d'où viennent les données.
Après test, je peux dire que j'ai dit une bétise et j'ai appris quelquechose.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 08-09-2013, Doug713705 nous expliquait dans fr.comp.os.linux.configuration :
Le 08-09-2013, Francois Lafont nous expliquait dans
fr.comp.os.linux.configuration :
En fait, la question que je me pose, c'est est-ce que le « | head »
interrompt vraiment le travail de la commande ls une fois qu'il a son
nombre de lignes souhaité (auquel cas ça me va car je sais alors que
la commande ls ne pompera pas trop de ressources réseaux quel que soit
le répertoire en face) ou bien ls continue-t-il son travail dans le
vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se
situe pas au niveau réseau puisque le ls va à son terme) ?
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la
sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les
deux commandes peuvent savoir où vont et/ou d'où viennent les données.
Après test, je peux dire que j'ai dit une bétise et j'ai appris
quelquechose.
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 08-09-2013, Doug713705 nous expliquait dans fr.comp.os.linux.configuration :
Le 08-09-2013, Francois Lafont nous expliquait dans fr.comp.os.linux.configuration :
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité (auquel cas ça me va car je sais alors que la commande ls ne pompera pas trop de ressources réseaux quel que soit le répertoire en face) ou bien ls continue-t-il son travail dans le vide malgré tout (et dans ce cas le gain constaté ci-dessus ne se situe pas au niveau réseau puisque le ls va à son terme) ?
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les deux commandes peuvent savoir où vont et/ou d'où viennent les données.
Après test, je peux dire que j'ai dit une bétise et j'ai appris quelquechose.
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Francois Lafont
Le 08/09/2013 13:58, Doug713705 a écrit :
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les deux commandes peuvent savoir où vont et/ou d'où viennent les données.
Ok, effectivement c'est logique. Donc, si je suis cette logique, imaginons que je suis dans le cas d'un partage nfs monté qui contient une tonne de fichiers à la racine, le gain de temps d'exécution constaté que j'obtiens avec :
ls -f /test | head > /dev/null
par rapport à :
ls -f /test > /dev/null
n'est pas lié au réseau. J'entends par là que la commande « ls -f » va jusqu'à son terme dans les 2 cas et demandera au serveur la liste intégrale des fichiers contenus dans le partage nfs. Et le gain que je constate empiriquement entre les deux commandes, c'est juste parce que dans le cas de la première commande un flux d'octets beaucoup plus court sera envoyé dans /dev/null que dans la seconde commande.
J'ai à peu près bon ?
En fait, je me disais que, *peut-être*, il pouvait se passer un truc du genre ça : le tail une fois qu'il a le nombre de ligne qui lui faut (ie 10 par défaut) casse le pipe et du coup la commande ls s'apercevant que le pipe est cassé se termine avant d'avoir listé tous les fichiers du partage. Il n'en ai rien donc, si j'ai bien compris ?
-- François Lafont
Le 08/09/2013 13:58, Doug713705 a écrit :
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la
sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les
deux commandes peuvent savoir où vont et/ou d'où viennent les données.
Ok, effectivement c'est logique. Donc, si je suis cette logique, imaginons
que je suis dans le cas d'un partage nfs monté qui contient une tonne de
fichiers à la racine, le gain de temps d'exécution constaté que j'obtiens
avec :
ls -f /test | head > /dev/null
par rapport à :
ls -f /test > /dev/null
n'est pas lié au réseau. J'entends par là que la commande « ls -f » va
jusqu'à son terme dans les 2 cas et demandera au serveur la liste intégrale
des fichiers contenus dans le partage nfs. Et le gain que je constate
empiriquement entre les deux commandes, c'est juste parce que dans le
cas de la première commande un flux d'octets beaucoup plus court
sera envoyé dans /dev/null que dans la seconde commande.
J'ai à peu près bon ?
En fait, je me disais que, *peut-être*, il pouvait se passer un truc du
genre ça : le tail une fois qu'il a le nombre de ligne qui lui faut (ie 10
par défaut) casse le pipe et du coup la commande ls s'apercevant que le
pipe est cassé se termine avant d'avoir listé tous les fichiers du partage.
Il n'en ai rien donc, si j'ai bien compris ?
A priori "pipe" porte bien son nom, c'est un simple tuyau qui relie la sortie d'une commande avec l'entrée d'une autre.
Il n'a pas de contrôle sur les commandes qu'il relie, pas plus que les deux commandes peuvent savoir où vont et/ou d'où viennent les données.
Ok, effectivement c'est logique. Donc, si je suis cette logique, imaginons que je suis dans le cas d'un partage nfs monté qui contient une tonne de fichiers à la racine, le gain de temps d'exécution constaté que j'obtiens avec :
ls -f /test | head > /dev/null
par rapport à :
ls -f /test > /dev/null
n'est pas lié au réseau. J'entends par là que la commande « ls -f » va jusqu'à son terme dans les 2 cas et demandera au serveur la liste intégrale des fichiers contenus dans le partage nfs. Et le gain que je constate empiriquement entre les deux commandes, c'est juste parce que dans le cas de la première commande un flux d'octets beaucoup plus court sera envoyé dans /dev/null que dans la seconde commande.
J'ai à peu près bon ?
En fait, je me disais que, *peut-être*, il pouvait se passer un truc du genre ça : le tail une fois qu'il a le nombre de ligne qui lui faut (ie 10 par défaut) casse le pipe et du coup la commande ls s'apercevant que le pipe est cassé se termine avant d'avoir listé tous les fichiers du partage. Il n'en ai rien donc, si j'ai bien compris ?
-- François Lafont
Francois Lafont
Le 08/09/2013 14:18, Doug713705 a écrit :
Après test, je peux dire que j'ai dit une bétise et j'ai appris quelquechose.
Heu... mais encore ? ;-)
-- François Lafont
Le 08/09/2013 14:18, Doug713705 a écrit :
Après test, je peux dire que j'ai dit une bétise et j'ai appris
quelquechose.
Après test, je peux dire que j'ai dit une bétise et j'ai appris quelquechose.
Heu... mais encore ? ;-)
-- François Lafont
Nicolas George
Francois Lafont , dans le message <522c56b8$0$2030$, a écrit :
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité
Quand le (ou les) programme qui lit sur un tuyau se termine, si un programme essaie d'écrire, il reçoit un SIGPIPE, dont l'action par défaut est de tuer. Si le signal est ignoré, l'opération d'écriture renverra une erreur EPIPE.
Il suffit de stracer ls pour se rendre compte qu'il n'ignore pas SIGPIPE.
Francois Lafont , dans le message
<522c56b8$0$2030$426a74cc@news.free.fr>, a écrit :
En fait, la question que je me pose, c'est est-ce que le « | head »
interrompt vraiment le travail de la commande ls une fois qu'il a son
nombre de lignes souhaité
Quand le (ou les) programme qui lit sur un tuyau se termine, si un programme
essaie d'écrire, il reçoit un SIGPIPE, dont l'action par défaut est de tuer.
Si le signal est ignoré, l'opération d'écriture renverra une erreur EPIPE.
Il suffit de stracer ls pour se rendre compte qu'il n'ignore pas SIGPIPE.
Francois Lafont , dans le message <522c56b8$0$2030$, a écrit :
En fait, la question que je me pose, c'est est-ce que le « | head » interrompt vraiment le travail de la commande ls une fois qu'il a son nombre de lignes souhaité
Quand le (ou les) programme qui lit sur un tuyau se termine, si un programme essaie d'écrire, il reçoit un SIGPIPE, dont l'action par défaut est de tuer. Si le signal est ignoré, l'opération d'écriture renverra une erreur EPIPE.
Il suffit de stracer ls pour se rendre compte qu'il n'ignore pas SIGPIPE.
Francois Lafont
Le 08/09/2013 15:30, Nicolas George a écrit :
Quand le (ou les) programme
La commande head dans mon exemple donc.
qui lit sur un tuyau se termine, si un programme essaie d'écrire, il reçoit un SIGPIPE,
De la part de qui ? De la part du processus head ou bien c'est le noyau lui-même, s'apercevant que le processus "ls" essaie d'écrire sur un « broken pipe », qui envoie SIGPIPE à "ls" ?
dont l'action par défaut est de tuer. Si le signal est ignoré, l'opération d'écriture renverra une erreur EPIPE.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Il suffit de stracer ls pour se rendre compte qu'il n'ignore pas SIGPIPE.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement pris en charge par ls.
Avec strace, c'est plus simple en effet :
~# export LC_ALL=C ~# { strace ls -f /test; } | head
qui lit sur un tuyau se termine, si un programme
essaie d'écrire, il reçoit un SIGPIPE,
De la part de qui ? De la part du processus head ou bien c'est le noyau
lui-même, s'apercevant que le processus "ls" essaie d'écrire sur
un « broken pipe », qui envoie SIGPIPE à "ls" ?
dont l'action par défaut est de tuer.
Si le signal est ignoré, l'opération d'écriture renverra une erreur EPIPE.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge
SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Il suffit de stracer ls pour se rendre compte qu'il n'ignore pas SIGPIPE.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai
simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement
pris en charge par ls.
Avec strace, c'est plus simple en effet :
~# export LC_ALL=C
~# { strace ls -f /test; } | head
qui lit sur un tuyau se termine, si un programme essaie d'écrire, il reçoit un SIGPIPE,
De la part de qui ? De la part du processus head ou bien c'est le noyau lui-même, s'apercevant que le processus "ls" essaie d'écrire sur un « broken pipe », qui envoie SIGPIPE à "ls" ?
dont l'action par défaut est de tuer. Si le signal est ignoré, l'opération d'écriture renverra une erreur EPIPE.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Il suffit de stracer ls pour se rendre compte qu'il n'ignore pas SIGPIPE.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement pris en charge par ls.
Avec strace, c'est plus simple en effet :
~# export LC_ALL=C ~# { strace ls -f /test; } | head
Francois Lafont , dans le message <522c8955$0$2139$, a écrit :
De la part de qui ? De la part du processus head ou bien c'est le noyau lui-même, s'apercevant que le processus "ls" essaie d'écrire sur un « broken pipe », qui envoie SIGPIPE à "ls" ?
{ sudo ls -R /; echo done >&2 } | head -n 2
Si c'est head qui envoie le signal, il n'a pas les droit pour tuer un ls lancé avec sudo.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Je pense que c'est un artefact de strace : l'appel système retourne EPIPE du point de vue de strace, mais le processus n'a jamais l'occasion de le voire.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement pris en charge par ls.
Ça me surprendrait.
Francois Lafont , dans le message
<522c8955$0$2139$426a74cc@news.free.fr>, a écrit :
De la part de qui ? De la part du processus head ou bien c'est le noyau
lui-même, s'apercevant que le processus "ls" essaie d'écrire sur
un « broken pipe », qui envoie SIGPIPE à "ls" ?
{ sudo ls -R /; echo done >&2 } | head -n 2
Si c'est head qui envoie le signal, il n'a pas les droit pour tuer un ls
lancé avec sudo.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge
SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Je pense que c'est un artefact de strace : l'appel système retourne EPIPE du
point de vue de strace, mais le processus n'a jamais l'occasion de le voire.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai
simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement
pris en charge par ls.
Francois Lafont , dans le message <522c8955$0$2139$, a écrit :
De la part de qui ? De la part du processus head ou bien c'est le noyau lui-même, s'apercevant que le processus "ls" essaie d'écrire sur un « broken pipe », qui envoie SIGPIPE à "ls" ?
{ sudo ls -R /; echo done >&2 } | head -n 2
Si c'est head qui envoie le signal, il n'a pas les droit pour tuer un ls lancé avec sudo.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Je pense que c'est un artefact de strace : l'appel système retourne EPIPE du point de vue de strace, mais le processus n'a jamais l'occasion de le voire.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement pris en charge par ls.
Ça me surprendrait.
Francois Lafont
Le 08/09/2013 17:05, Nicolas George a écrit :
De la part de qui ? De la part du processus head ou bien c'est le noyau lui-même, s'apercevant que le processus "ls" essaie d'écrire sur un « broken pipe », qui envoie SIGPIPE à "ls" ?
{ sudo ls -R /; echo done >&2 } | head -n 2
Si c'est head qui envoie le signal, il n'a pas les droit pour tuer un ls lancé avec sudo.
Ok, c'est donc le noyau qui envoie le SIGPIPE.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Je pense que c'est un artefact de strace : l'appel système retourne EPIPE du point de vue de strace, mais le processus n'a jamais l'occasion de le voire.
Ok.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement pris en charge par ls.
Ça me surprendrait.
Là, j'avoue ne pas trop comprendre, tu disais plus haut que ls n'ignore pas SIGPIPE ?
En fait, je pensais que, mis à part quelques signaux comme KILL et STOP, un programme ne tenait compte d'un signal (comme SIGPIPE par exemple) que si le-dit programme prenait en charge le signal dans son implémentation (en gros je pensais qu'un programme où il n'y avait pas de code implémentant la prise en charge de SIGPIPE ignorait de fait ce signal). Ce n'est pas comme cela que ça se passe ?
Sinon, pour ceux que ça intéressent, voici le script shell que je compte utiliser pour faire mon check du coup :
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
done ----
* J'aurais une sortie que je pourrais parser côté serveur.
* Le script suppose que les répertoires de montage ne possèdent pas, entre autres, d'espace dans leur nom. J'avoue que prendre en compte cette éventualité me semble bien compliqué (d'ailleurs là, comme ça, je ne sais même pas comme je pourrais m'y prendre), mais étant donné qu'il faut vraiment être tordu pour choisir un point de montage sur un serveur avec des espaces dans le nom...
* J'essaye d'exclure du check certains points de montage un peu spéciaux (/dev/xxx, /proc etc). Sans doute que la liste n'est pas assez exhaustive mais ce n'est pas le propos du fil ici.
Si jamais vous avez des remarques, bien sûr n'hésitez pas, je suis toujours preneur. ;-)
-- François Lafont
Le 08/09/2013 17:05, Nicolas George a écrit :
De la part de qui ? De la part du processus head ou bien c'est le noyau
lui-même, s'apercevant que le processus "ls" essaie d'écrire sur
un « broken pipe », qui envoie SIGPIPE à "ls" ?
{ sudo ls -R /; echo done >&2 } | head -n 2
Si c'est head qui envoie le signal, il n'a pas les droit pour tuer un ls
lancé avec sudo.
Ok, c'est donc le noyau qui envoie le SIGPIPE.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge
SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Je pense que c'est un artefact de strace : l'appel système retourne EPIPE du
point de vue de strace, mais le processus n'a jamais l'occasion de le voire.
Ok.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai
simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement
pris en charge par ls.
Ça me surprendrait.
Là, j'avoue ne pas trop comprendre, tu disais plus haut que ls n'ignore pas
SIGPIPE ?
En fait, je pensais que, mis à part quelques signaux comme KILL et STOP,
un programme ne tenait compte d'un signal (comme SIGPIPE par exemple) que
si le-dit programme prenait en charge le signal dans son implémentation
(en gros je pensais qu'un programme où il n'y avait pas de code implémentant
la prise en charge de SIGPIPE ignorait de fait ce signal). Ce n'est pas
comme cela que ça se passe ?
Sinon, pour ceux que ça intéressent, voici le script shell que je compte
utiliser pour faire mon check du coup :
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
done
----
* J'aurais une sortie que je pourrais parser côté serveur.
* Le script suppose que les répertoires de montage ne possèdent pas,
entre autres, d'espace dans leur nom. J'avoue que prendre en compte
cette éventualité me semble bien compliqué (d'ailleurs là, comme ça,
je ne sais même pas comme je pourrais m'y prendre), mais étant donné
qu'il faut vraiment être tordu pour choisir un point de montage sur
un serveur avec des espaces dans le nom...
* J'essaye d'exclure du check certains points de montage un peu
spéciaux (/dev/xxx, /proc etc). Sans doute que la liste n'est pas
assez exhaustive mais ce n'est pas le propos du fil ici.
Si jamais vous avez des remarques, bien sûr n'hésitez pas, je suis
toujours preneur. ;-)
De la part de qui ? De la part du processus head ou bien c'est le noyau lui-même, s'apercevant que le processus "ls" essaie d'écrire sur un « broken pipe », qui envoie SIGPIPE à "ls" ?
{ sudo ls -R /; echo done >&2 } | head -n 2
Si c'est head qui envoie le signal, il n'a pas les droit pour tuer un ls lancé avec sudo.
Ok, c'est donc le noyau qui envoie le SIGPIPE.
Ci-dessous j'ai bien une erreur EPIPE. Si ls prend bien en charge SIGPIPE, on pourrait s'attendre à ne pas avoir cette erreur du coup, non ?
Je pense que c'est un artefact de strace : l'appel système retourne EPIPE du point de vue de strace, mais le processus n'a jamais l'occasion de le voire.
Ok.
Bien vu et merci. Perso j'avais regardé dans le code source de ls et j'ai simplement vu, qu'apparemment (moi et le C...), SIGPIPE était effectivement pris en charge par ls.
Ça me surprendrait.
Là, j'avoue ne pas trop comprendre, tu disais plus haut que ls n'ignore pas SIGPIPE ?
En fait, je pensais que, mis à part quelques signaux comme KILL et STOP, un programme ne tenait compte d'un signal (comme SIGPIPE par exemple) que si le-dit programme prenait en charge le signal dans son implémentation (en gros je pensais qu'un programme où il n'y avait pas de code implémentant la prise en charge de SIGPIPE ignorait de fait ce signal). Ce n'est pas comme cela que ça se passe ?
Sinon, pour ceux que ça intéressent, voici le script shell que je compte utiliser pour faire mon check du coup :
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
done ----
* J'aurais une sortie que je pourrais parser côté serveur.
* Le script suppose que les répertoires de montage ne possèdent pas, entre autres, d'espace dans leur nom. J'avoue que prendre en compte cette éventualité me semble bien compliqué (d'ailleurs là, comme ça, je ne sais même pas comme je pourrais m'y prendre), mais étant donné qu'il faut vraiment être tordu pour choisir un point de montage sur un serveur avec des espaces dans le nom...
* J'essaye d'exclure du check certains points de montage un peu spéciaux (/dev/xxx, /proc etc). Sans doute que la liste n'est pas assez exhaustive mais ce n'est pas le propos du fil ici.
Si jamais vous avez des remarques, bien sûr n'hésitez pas, je suis toujours preneur. ;-)
-- François Lafont
Nicolas George
Francois Lafont , dans le message <522c9a5c$0$2141$, a écrit :
En fait, je pensais que, mis à part quelques signaux comme KILL et STOP, un programme ne tenait compte d'un signal (comme SIGPIPE par exemple) que si le-dit programme prenait en charge le signal dans son implémentation (en gros je pensais qu'un programme où il n'y avait pas de code implémentant la prise en charge de SIGPIPE ignorait de fait ce signal). Ce n'est pas comme cela que ça se passe ?
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.
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.
Francois Lafont , dans le message
<522c9a5c$0$2141$426a74cc@news.free.fr>, a écrit :
En fait, je pensais que, mis à part quelques signaux comme KILL et STOP,
un programme ne tenait compte d'un signal (comme SIGPIPE par exemple) que
si le-dit programme prenait en charge le signal dans son implémentation
(en gros je pensais qu'un programme où il n'y avait pas de code implémentant
la prise en charge de SIGPIPE ignorait de fait ce signal). Ce n'est pas
comme cela que ça se passe ?
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.
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.
Francois Lafont , dans le message <522c9a5c$0$2141$, a écrit :
En fait, je pensais que, mis à part quelques signaux comme KILL et STOP, un programme ne tenait compte d'un signal (comme SIGPIPE par exemple) que si le-dit programme prenait en charge le signal dans son implémentation (en gros je pensais qu'un programme où il n'y avait pas de code implémentant la prise en charge de SIGPIPE ignorait de fait ce signal). Ce n'est pas comme cela que ça se passe ?
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.
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.
