Ubuntu-fr

Plug

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Alors d'après mes tests nous avons 2 problèmes :

• le ExitOnForwardFailure ne renvoie pas de Warning. Il sort avec un code 255.

• Ce qui est fait dans le processus fils (celui de la substitution de processus) ne remonte pas

i.e. le echo $((reverse_port+1)) affiche bien le port incrémenté à l'écran mais il n'est pas récupéré par la variable à laquelle on affecte le résultat de la commande, à savoir reverse_port=$(cmd

NB: le code 255 n'est pas exploitable.

kamaris

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Humm… bizarre dans les deux cas :

• pourquoi le code 255 ne serait pas exploitable ? Pourquoi ne serait-il pas possible de faire

  while ! ssh -i -NT -o ExitOnForwardFailure -R $reverse_port:localhost:$local_port $user@$server -p $remote_port; do ((reverse_port++)); done

• quelle commande as-tu exécutée exactement pour aboutir à un tel résultat (je suspecte une redirection de la sortie standard vers la sortie d'erreur) ?

Plug

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

pourquoi le code 255 ne serait pas exploitable ?

Parce qu'il n'est pas spécifique.
Par exemple si ton serveur est éteint, ssh va te retourner un 255.
Tu pourras boucler autant que tu veux, ça ne va pas allumer ton serveur

quelle commande as-tu exécutée exactement ?

Je n'ai plus la connexion avec le pc, mais je refais le test dès que je la récupère et je post tout.

Mais une chose est constante, ce que je ne m'explique pas :
Si j'essaie d'affecter le résultat de ma commande à une variable

var=$(ssh ...

la commande reste en attente et je ne récupère rien dans ma variable.
Mais si je ferme la connexion côté serveur, là je récupère bien un message dans $var

kamaris

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Bon, j'aurais bien comme l'impression qu'on tourne un peu en rond, non ?
Donc, si pas moyen d'exploiter le code retour, pas moyen d'exploiter l'option ExitOnForwardFailure, et pas moyen d'affecter une variable : on repart sur le schéma kill / trap donné en #16.
Je le précise cette fois-ci jusqu'au bout :

script_pid=$BASHPID
start_ssh() {
ssh -i -NT -R $reverse_port:localhost:$local_port $user@$server -p $remote_port 2> >(grep -q 'Warning' && kill -s RTMIN $script_pid) &
wait
sleep 0.1
}
trap 'killall ssh; ((reverse_port++)); start_ssh' RTMIN
start_ssh

Ce schéma-là bouclera de lui-même, par la présence du start_ssh dans le trap (le start_ssh en dernière ligne ne servant qu'à l'initialisation du processus).
Si j'ai bien compris, dans ton script il n'y aurait essentiellement que ça, c'est-à-dire qu'il suffirait de rajouter au dessus le shebang et l'initialisation des variables pour avoir le script complet.

Plug

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Oui, ça rend fou ce truc hein ?

le shebang et l'initialisation des variables pour avoir le script complet

Exact (au -f près). Après j'aimerais bien envoyer un message du genre "Remote Forward OK" en sortie de boucle, mais bon, c'est optionnel.

Une question quand même sur le wait. Tu me dis :

Le sleep 0.1 à la fin, c'est pour que le script existe encore lorsque le signal envoyé lui parvient

et après :

Ça n'est pas parce que la commande kill s'appelle « kill » qu'elle (ne) sert (qu')à tuer

Donc, ce qui me semble logique au vu des éléments dont je dispose, si le kill ne tue pas, pourquoi faudrait-il attendre que le script existe encore ?
J'avoue, là tu m'as perdu

kamaris

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Le -f ne devrait pas être nécessaire, puisqu'ici on lance explicitement la commande ssh en arrière plan.
Essaie d'abord avec ce code, et pour la suite, si ça ne fonctionne pas, il faudrait que tu donnes très précisément la commande exécutée et son retour, pour qu'on puisse avancer sur des bases claires.
Quant au « Remote Forward OK », on verra ça quand on aura un truc qui marche, chaque chose en son temps

Concernant le sleep 0.1, l'explication est la suivante :

• le « kill -s RTMIN $script_pid » se trouve dans un commande lancée en arrière plan ;

• après cette commande, il y a un « wait », qui assure que le script attendra que tout processus fils en arrière plan se termine avant de continuer ;

• si il n'y a rien après le wait (ce qui est le cas ici si on enlève le sleep 0.1, puisque start_ssh est la dernière commande lancée), alors une fois que tous les processus fils sont terminés, le script se termine à son tour.

Maintenant voici ce qui peut se passer aléatoirement (selon l'ordonnancement des tâches) : kill envoie son signal RTMIN au script, le processus en arrière plan (contenant kill) se termine, donc la commande wait se termine, et le script passe à la suite, c'est-à-dire se termine aussi, avant d'avoir reçu le signal RTMIN.
Dans ce cas là, tu auras un message d'erreur te disant que kill n'a pas trouvé de processus $script_pid à qui envoyer son signal.
Donc en mettant un sleep 0.1 en plus du wait, tu t'assures que le script aura le temps de recevoir le signal, ce qui le fera embrayer sur la commande trap, laquelle relancera ssh en arrière plan, etc.

Plug

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Limpide. Tu es prof ou quoi ?

Alors j'en profite Pourquoi mettre un killall dans ton trap ?

1. Ne risque-t-il pas d'interférer avec le script en générant une erreur ("rien à tuer") qui pourrait perturber le trap ?
   Car je suppose que si la commande a renvoyé un Warning c'est qu'elle est terminée, non ? Donc le killall ne sert pas.

2. Quelle est sa portée ? (car je ne voudrais pas qu'il me tue toutes les connexions ouvertes par ailleurs )

kamaris

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Ne risque-t-il pas d'interférer avec le script en générant une erreur ("rien à tuer") qui pourrait perturber le trap ?

Il génèrera effectivement un message d'erreur, avec un code retour non nul dans ce cas, mais ça ne perturbera pas le trap.
Si tu veux qu'il ne dise rien dans le cas où aucun processus ssh n'existe, il suffit de faire killall -q ssh.

Car je suppose que si la commande a renvoyé un Warning c'est qu'elle est terminée, non ? Donc le killall ne sert pas.

Eh bien justement, ça je n'en sais rien
Nos échanges qui précèdent m'ont plutôt suggéré le contraire, puisque tu disais qu'en interactif, ssh ne te rendait pas la main, qu'il y ait warning ou non (mais j'ai peut-être mal compris).

Quelle est sa portée ? (car je ne voudrais pas qu'il me tue toutes les connexions ouvertes par ailleurs )

Ah effectivement, tel quel, il tuera tous les processus ssh : j'avais supposé qu'il n'y en avait pas d'autres que ceux lancés par le script.
Après, il y a divers moyens de restreindre le champ, dont les options --older-than et --younger-than de killall, ou bien utiliser d'autres commandes, comme pkill --newest ssh.
Mais bon, dans un premier temps, tu peux enlever ça si tu veux : l'essentiel est de savoir si le code en #29 te permet bien de relancer un port forwarding qui fonctionne en cas de warning.

Plug

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Voilà j'ai enfin pu tester (le PC était en vadrouille   )

L’incrémentation du port se passe comme prévue et au final le remote forward s'installe bien. Bravo kamaris !

En revanche, le script bloque sur

+ grep -q Warning

quand il n'y a pas de Warning (i.e. quand le forward s'installe bien) ...

Même un CTRL <C> ne l'arrête pas. Il faut tuer le process pour reprendre la main.

kamaris

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Que le grep reste en vie tant que ssh continue à lui envoyer une sortie, c'est normal (c'est un peu ce qu'on lui demande…)
Quant au script, il ne devrait pas ignorer ctrl-c, donc il devrait rendre la main, mais sans que ça tue pour autant le grep, qui devrait être rattaché au process de pid 1 à la mort du script.

Si tu veux que le script fasse quelque chose de particulier quand tu fais ctrl-c, il faut que tu rajoutes un trap pour le signal INT (signal numéro 2, celui qui est envoyé quand tu fais ctrl-c).
Par exemple, tu peux lui demander de killer la dernière commande ssh lancée, et de sortir en donnant le code retour de cette commande kill :

trap 'pkill --newest ssh; exit' INT

Attention : ce trap doit être placé avant l'autre dans le script, car il faut que le script en ait connaissance avant d'entrer dans la boucle qu'engendre le second trap.

Dernière modification par kamaris (Le 22/01/2020, à 23:26)

Plug

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

Alors voilà ce que j'ai fait pour débloquer :

• j'ai supprimé le wait

• j'ai un peu augmenté le sleep

Mon raisonnement :

• Le trap agit à réception du "Warning".

• Le "Warning" arrive relativement vite (un aller-retour entre client et serveur)

• Donc en attendant 2 secondes, j'ai bien mon trap

Le wait n'est plus nécessaire et du coup lorsque la commande réussit (sans warning) le script passe à la suite au bout de 2 secondes et je peux afficher mon message de réussite

Qu'en penses-tu ?

kamaris

Re : [Résolu] Script - Gestion des erreurs - Récupérer un Warning

C'est une possibilité, oui, si tu es sûr que tu ne louperas pas le warning.
Comme je ne connais pas assez les cas d'utilisation de ssh, je pensais que le warning pouvait intervenir un temps indéterminé après que la commande a été lancée.
J'ai quand même l'impression qu'on loupe quelque chose dans la gestion des retours d'ssh, mais comme encore une fois je ne connais pas assez, je ne peux pas en dire tellement plus (peut-être qu'on ne loupe rien d'ailleurs).
En tout cas au final, si ça marche comme ça, c'est déjà pas mal