Discussion :

[Marty69]

Hello,

alors voila mon dilemme !

j'ai un ordinateur sous Debian Jessie qui récupère un flux vidéo et le stream sur le réseau. Pour ce faire j'exécute en local la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sudo ./bmd-streamer -K 10000 -P main | avconv -i - -vcodec copy -acodec copy -f mpegts udp://239.255.1.1:1234

lancée comme cela, en local, pas de problème ca fonctionne.

Mes difficultés arrivent quand je doit lancer le tout à distance et que tout doit tourner en autonome. L'ordinateur en question est ailleurs dans le batiment, sans écran et clavier. Je dois pouvoir le gérer à distance en SSH.

1) j'aimerais lancer le tout depuis un script shell en SSH
2) ce script doit pouvoir être lancé en arrière plan (reprendre la main et le laisser tourner)
3) Enfin, une fois lancé je dois pouvoir quitter le SSH sans couper l'exécution du script

Et la je suis perdu !

Merci pour votre aide

[frp31]

la solution la plus logique et la plus simple à la fois
est de te connecter une fois en ssh et creer le script équivalant à ta commande en replacant eventuellement certains elements par les parametres donnés en arguments...

et de le lancer en mode nohup
genre ssh user@machine "nohup /chemin/local/vers/toto.sh IP.ip.ip.ip port &"une autre solution tout aussi pratique étant de le lancer dans un tmux ou un screen en (detach) que tu peux donc rependre quand tu veux (attach)

là encore ça laisse tourner en arrière plan meme si tu te deconnectes totalement.

[Marty69]

Salut,

merci beaucoup pour les suggestions.
J'avoue pratiquer linux depuis longtemps mais je n'ai jamais vraiment mis les mains dans les scripts !
Du coup j'ai bien compris (je crois) la première solution, par contre le reste j'ai clairement pas tout saisi

Pour récapituler :
- je crée un script /home/user/stream.sh qui contient

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
#!/bin/bash
sudo ./bmd-streamer -K 10000 -P main | avconv -i - -vcodec copy -acodec copy -f mpegts udp://239.255.1.1:1234

- je rend ce script exécutable
- (au passage j'ai ajouté une clause NOPASSWD: /home/user/stream.sh dans le sudoers, le script devrait se lancer sans me demander de mot de passe, j'ai bon ?)
- depuis une machine distante je lance

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ssh user@machine "nohup /home/user/stream.sh IP.ip.ip.ip port &"

- je ferme ma console ssh et je vais prendre un café...

La solution du screen me parrait intéressante, tu peux préciser un peu ? et quel serait l'utilité du screen plutôt qu'un nohup ?

merci beaucoup

[Sve@r]

- depuis une machine distante je lance

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ssh user@machine "nohup /home/user/stream.sh IP.ip.ip.ip port &"

Salut

Pas besoin de nohup, c'est inclus automatiquement par le ssh. Et t'as pas besoin non plus que le script fasse de sudo puisque tu peux préciser l'utilisateur voulu au ssh.

- je ferme ma console ssh et je vais prendre un café...

Faut tout de même appuyer sur "ctrl-c" car même avec le "&", le ssh attend la fin du processus lancé. Donc un "ctrl-c" pour interrompre le ssh ce qui n'est pas grave puisque le script a démarré puis le café. Tu peux même te déconnecter de ton poste, ça n'a aucun effet sur le script qui s'exécute, lui, sur le poste distant.

La solution du screen me parrait intéressante, tu peux préciser un peu ? et quel serait l'utilité du screen plutôt qu'un nohup ?

Ca n'a pas le même rôle. Le nohup sert à lancer une grosse tâche qui continuera même après déconnexion éventuelle et pour laquelle tu n'as pas besoin d'intéragir. Le screen sert à lancer plusieurs tâches en arrière-plan avec leur display tout en gardant le contrôle pour y revenir si besoin (donc pas de déconnexion possible).
Un screen c'est (grosso-modo) un processus+l'écran qui l'affiche. Tu lances un processus dans un screen (commande screen programme) il commence à s'afficher normalement (comme si t'avais appelé le programme directement). Toutefois tu as possibilité de l'envoyer en arrière-plan en appuyant sur ctrl+a puis d.
A ce moment là, tu peux alors répéter l'opération pour d'autres programmes.

Ensuite, quand tu veux revenir sur l'un d'entre eux, tu tapes screen -d. Ca t'affiche alors tous les screens lancés. Te suffit de repérer celui qui t'intéresse (pas évident toutefois car ça ne te donne pas le nom du programme lancé ce qui aurait été appréciable) et te suffit alors de taper screen -r pid_du_screen_a_récupérer. Il revient alors à l'écran avec son affichage en cours. Tu peux alors finir de le suivre, répondre à ses questions s'il y en a, ou alors le renvoyer de nouveau avec ctrl-a puis d.
Toutefois le screen doit être lancé depuis un terminal donc tu ne peux pas lancer un screen dans un ssh. Ceci dit, tu peux lancer un ssh dans un screen...

[Marty69]

Mercipour ta réponse

Pas besoin de nohup, c'est inclus automatiquement par le ssh. Et t'as pas besoin non plus que le script fasse de sudo puisque tu peux préciser l'utilisateur voulu au ssh.

Faut tout de même appuyer sur "ctrl-c" car même avec le "&", le ssh attend la fin du processus lancé. Donc un "ctrl-c" pour interrompre le ssh ce qui n'est pas grave puisque le script a démarré puis le café. Tu peux même te déconnecter de ton poste, ça n'a aucun effet sur le script qui s'exécute, lui, sur le poste distant.

Et bien c'est justement la ou est le problème : quand je lance cette commande dans un terminal connecté en SSH, d'une part quand je fait CTRL+C avconv continue de tourner mais aussi quand je quitte le terminal le processus s'arrête !

[frp31]

c'est pourquoi le nohup est obligatoire

[Sve@r]

Faut vérifier si cela ne vient pas de aconv.

Moi, pour mes essais, voici le script que j'ai écrit

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#!/bin/bash
 
fic="/tmp/res.$$"
>"$fic"
for i in $(seq $1)
do
	echo "$$ $i $(date)" >>"$fic"
	sleep 5
done

Je l'ai nommé "/tmp/essai.sh" puis j'ai tapé ssh localhost "/tmp/essai.sh 20 &". Ben je peux quitter ssh par ctrl-c et fermer le terminal, le fichier /tmp/res.pid continue à grossir...

[Marty69]

ok, bon ben en fait lancer le script sans nohup fonctionne.
je me connecte et lance le script

sudo monscript.sh &

et tout roule...

étrange mais ca fonctionnait pas la dernière fois...

Merci à vous en tout cas !

[Sve@r]

c'est pourquoi le nohup est obligatoire

Ben justement non !!! Je me demande vraiment parfois pourquoi je me fatigue à expliquer les essais que j'ai fait...
Et même si on ne met pas le "&" ça continue quand-même à tourner !!!

étrange mais ca fonctionnait pas la dernière fois...

Moi ça m'est arrivé que, ayant fait des tests entre deux hosts distincts pour être sûr d'être en conditions réelles (malgré le fait que localhost reproduise un comportement identique au réseau ethernet je voulais quand-même passer par le cable), et ayant quitté trop tôt le ssh, celui-ci n'avait pas eu le temps de dialoguer avec le host distant et que celui-ci n'ait alors pas lancé le script. J'ai donc bien veillé à ce que le fichier "/tmp/res.xxx" commence à grossir sur le host distant pendant que mon ssh du host de départ me montrait le déroulement (j'ai rajouté un echo en plus dans mon script). Alors seulement j'ai stoppé le ssh. Et sur le host distant, le fichier continuait à grossir et le processus apparaissait bien au ps.
En plus tant que le ssh était en fonction sur le host de départ, le processus "xxx" du host distant était rattaché au processus sshd qui gère le serveur ssh. Et quand, sur le premier host je quittais le ssh, le processus "essai.sh" du host distant se voyait rattaché au init (comportement standard du nohup).

[disedorgue]

Bonjour,

Pour l'histoire du nohup, il faut savoir que celui-ci bloc l'envoi du SIGHUP (entre autre), qui est la fermeture du terminal.
Or, ssh host suivi d'une commande, n'ouvre pas de terminal (il n'y a donc pas de SIGHUP à envoyer au process).
D'ailleurs, si on rajoute l'option "-t" à la commande ssh, cette fois-ci, le process s'arrêtera aussi après le CTRL-C.