La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Iperf => Discussion démarrée par: vivien le 02 février 2012 à 22:08:13
-
Voici quelques scripts pour mettre en place un serveur IPERF public.
IPERF peut planter (certaines lignes de commandes), IPERF peut se bloquer (plutôt rare)
La seule solution que j'ai trouvé est la mise en place de script qui :
- vérifie chaque minute que IPERF est bien lancé
- Redémarre de force IPERF toutes les 6h (à 0h59, 6:59, 12h59, 18h59 dans mon exemple)
Pour Debian / Ubuntu, je recommande la version d'IPERF Iperf 2.0.2-4 et la 2.0.5-2.
Les autres versions sont à éviter.
Dans la contab d'un utilisateur crée spécialement pour iperf, je mets :
* * * * * /home/scripts/check_i-p-e-r-f.sh 2>&1
59 */6 * * * /home/scripts/restart_i-p-e-r-f.sh 2>&1
L'utilisateur crée spécialement pour IPERF (pour des raisons de sécurité) et le nom des scripts ne doivent pas contenir le mot IPERF sans quoi le ps x | grep iperf va dire que iperf est toujours en vie.
C'est la raison pour laquelle j'ai employé i-p-e-r-f à la place de iperf.
Ce n'est pas propre mais c'est fait rapidement et cela fonctionne.
le scrip check_i-p-e-r-f.sh
#!/bin/sh
if [ `ps x | grep iperf | grep -v grep | grep -vi screen | wc -l` = "0" ]
then
cd ~/scripts
date >> /home/log/i-p-e-r-f/plantage_i-p-e-r-f.log
date >> /home/log/i-p-e-r-f/log_i-p-e-r-f.log
#/usr/bin/iperf -s > /dev/null &
/usr/bin/iperf -s >> /home/log/i-p-e-r-f/log_i-p-e-r-f.log &
fi
le script restart_i-p-e-r-f.sh
#!/bin/sh
/bin/sleep 20
/usr/bin/killall iperf
/bin/sleep 1
/usr/bin/killall -9 iperf
/bin/sleep 1
if [ `ps x | grep iperf | grep -v grep | grep -vi screen | wc -l` = "0" ]
then
cd ~/scripts
date >> /home/log/i-p-e-r-f/restart_6h_i-p-e-r-f.log
date >> /home/log/i-p-e-r-f/log_i-p-e-r-f.log
#/usr/bin/iperf -s > /dev/null &
/usr/bin/iperf -s >> /home/log/i-p-e-r-f/log_i-p-e-r-f.log &
fi
Le premier Sleep est pour éviter la collision entre le script qui s’exécute toute les minutes et celui qui s’exécute toutes les 6h.
Le second est pour laisser une chance à IPERF de se fermer proprement avant le kill -9
Le troisième sleep est nécessaire (si on test immédiatement la présence du process après l'avoir killer, il peut pense que le process est toujours là.
Les scripts sont à adapter à votre besoin !
N'hésitez pas à me poser des questions sur IPERF.
-
ps x | grep iperf | grep -v grep | grep -vi screen | wc -l
Beurk!
Que c'est moche...
-
le "screen" je vois pas l'intérêt
par contre la ligne de commande est bonne, pourquoi dis tu "beurk" ?
juste il faudrait remplacer les backquotes par $(commande) puisque c'est deprecated
-
par contre la ligne de commande est bonne, pourquoi dis tu "beurk" ?
Parce que c'est vraiment moche. ???
Pourquoi lancer 5 processus, quand un seul suffit :
if [ ! $(pidof "/usr/bin/iperf") ]Plus joli, non ?
-
Mais ça ne me parait pas correct?
-
juste il faudrait remplacer les backquotes par $(commande) puisque c'est deprecated
Comment ça "deprecated"?
-
Mais ça ne me parait pas correct?
Exact, il manquait au moins l'inversion (pidof retourne 0 quand il a trouvé un processus, 1 dans le cas contraire), j'ai édité.
À tester, évidemment, ce n'est qu'une solution plus élégante (à mon avis), parmi tant d'autres (pgrep c'est chouette, aussi).
Si le serveur de Vivien tourne sous Debian ou Ubuntu, le mieux à faire aurait encore été de gérer le serveur iperf via la commande start-stop-daemon.
-
Comment ça "deprecated"?
"deprecated" ou pas, c'est plutôt naze les backquotes.
La syntaxe $(commande) est vachement plus lisible (toujours à mon avis), et a - surtout - le mérite de permettre l'imbrication d'appels.
-
"deprecated" ou pas, c'est plutôt naze les backquotes.
La syntaxe $(commande) est vachement plus lisible (toujours à mon avis), et a - surtout - le mérite de permettre l'imbrication d'appels.
100 % d'accord. Je n'utilise que $()
Mais la disparition même lointaine de `cela` me parait plus qu'improbable, donc il me parait plus pertinent de parler des avantages évidents de $() que d'une "déprécation".
-
le "screen" je vois pas l'intérêt
Le screen, c'est pour regarder les tests en temps réel.
Il est préférable d'envoyer la sortie vers un fichier et de faire "tail -f fichier" pour regarder en temps réel les logs.
-
Parce que c'est vraiment moche. ???
Pourquoi lancer 5 processus, quand un seul suffit :
if [ ! $(pidof "/usr/bin/iperf") ]Plus joli, non ?
Joli, mais faux :
(pidof retourne 0 quand il a trouvé un processus, 1 dans le cas contraire)
if pidof ...
À tester, évidemment, ce n'est qu'une solution plus élégante (à mon avis), parmi tant d'autres (pgrep c'est chouette, aussi).
Si /usr/bin/iperf n'est pas une image exécutable mais un script, je pense que ça ne marche pas. (Je trouve assez moche que les scripts ne soient pas directement exécutables sous nix.)
La solution la plus simple, si une seule instance doit s'exécuter à la fois :
echo $! >/var/run/iperf.pid
-
Si le serveur de Vivien tourne sous Debian ou Ubuntu, le mieux à faire aurait encore été de gérer le serveur iperf via la commande start-stop-daemon.
Je suis sous Ubuntu server mais là je ne sais pas faire.
Si tu a une idée pour faire la même chose (pas seulement start / stop mais aussi le check toutes les minutes pour vérifier si il a planté et le restart toutes les 4h pour d'autres type de plantages), je suis preneur.
En plus je pense que mes connaissances pour mettre le script au démarrage du serveur avec update-rc.d pour mettre a jour les différents niveau init.d est maintenant déprécié ;D
Voici ce que j'avais noté dans mon fichier mémo sur le sujet :
Avant d'exécuter la commande update-rc.d il est important que ce que vous désirez démarrer ou stopper se trouve bien dans le répertoire /etc/init.d sous forme de script.
Vous devez donc en général toujours avoir dans votre script au minimum :
#!/bin/sh
case $1 in
start) ...
...
;;
stop) ...
...
;;
esac
# end
update-rc.d est un utilitaire fourni par Debian pour rapidement installer et supprimer les scripts de démarrage (System-V). Il permet de mettre à jour rapidement les script se trouvant dans /etc/rcx.d/XXscript vers les scripts de trouvant dans /etc/init.d/
update-rc.d [-n] [-f] name remove
update-rc.d [-n] name defaults [NN | NN-start NN-stop]
update-rc.d [-n] [-f] mon_script start|stop priorité runlevel1 runlevel2 ... . start|stop priorité runlevel1 runlevel2 . etc...
Le paramètre -n permet de ne pas modifier et de juste voir ce que ferais la commande si vous l'aviez exécutée (en gros ça ne modifie rien).
Le paramètre -f permet de forcer la suppression, même si /etc/init.d/script existe.
La priorité n'est pas obligatoire. Si vous omettez la priorité, alors init la mettra en 20.
Exemple : pour Démarrer le daemon xfs dans les niveaux 2,3,4,5 et le stopper dans les niveaux 0,1,6 pour une priorité 20, vous devez créer un script xfs (en vous inspirant de ceux présents dans /etc/init.d/), le rendre exécutable et le placer dans /etc/init.d/.
Il vous reste à créer les liens symboliques par : update-rc.d xfs start 20 2 3 4 5 . stop 20 0 1 6 .
Autre exemple avec que des strat : update-rc.d xfs start 20 2 3 4 5 .
Exemple avec l'utilisation de default : update-rc.d xfs defaults 19
/etc/rc0.d/K19xfs -> /etc/init.d/xfs
/etc/rc1.d/K19xfs -> /etc/init.d/xfs
/etc/rc6.d/K19xfs -> /etc/init.d/xfs
/etc/rc2.d/S19xfs -> /etc/init.d/xfs
/etc/rc3.d/S19xfs -> /etc/init.d/xfs
/etc/rc4.d/S19xfs -> /etc/init.d/xfs
/etc/rc5.d/S19xfs -> /etc/init.d/xfs
Pour désactiver le script (supprimer les modules) : update-rc.d -f xfs remove
-
Les "niveaux d'exécution" sont une abomination.
Je ne comprends pas que ça existe encore.
-
Joli, mais faux :if pidof ...
L'explication laissait à désirer (ce n'est pas le code retour de la commande qui est testé, mais sa sortie standard), mais le code proposé est fonctionnellement identique à celui qu'utilise Vivien (j'ai fait quelques tests).
Je suis sous Ubuntu server mais là je ne sais pas faire.
Si tu a une idée pour faire la même chose (pas seulement start / stop mais aussi le check toutes les minutes pour vérifier si il a planté et le restart toutes les 4h pour d'autres type de plantages), je suis preneur.
Je ne sais pas si tu as vu, mais j'ai envoyé un mail à la "rédaction" ce matin.
Quels sont ces autres types de plantages auxquels tu fais allusion ?
-
Parce que c'est vraiment moche. ???
Pourquoi lancer 5 processus, quand un seul suffit :
if [ ! $(pidof "/usr/bin/iperf") ]Plus joli, non ?
ah oui connaissait pas pidof, merci
-
Comment ça "deprecated"?
oui l'utilisation de backquotes est deprecated depuis l'invention des shells autres que bourne :
https://en.wikipedia.org/wiki/Grave_accent (https://en.wikipedia.org/wiki/Grave_accent)
en outre ici quelques explications sur les raisons :
http://mywiki.wooledge.org/BashFAQ/082 (http://mywiki.wooledge.org/BashFAQ/082)
-
oui l'utilisation de backquotes est deprecated depuis l'invention des shells autres que bourne :
https://en.wikipedia.org/wiki/Grave_accent (https://en.wikipedia.org/wiki/Grave_accent)
Source?
-
Source?
je t'ai répondu en mp
ce n'est pas le sujet du topic
-
Donc les backticks ne sont pas "deprecated", c'est bien ce que je pensais.
-
J'ai également une petite question un peu HS :
Quelle est la méthode conseillée aujourd'hui pour démarrer un script au démarrage du serveur ?
Je me demande si de mettre l'appel du script dans /etc/rc.local n'est pas obsolescente...
L'utilisation de init "run-levels" me semble plus propre mais Upstart semble l'avoir rendu obsolète.
Upstart (initctl start nouveau-job) est-il ce qui est conseillé ?