Bon, j'ai déjà eu du mal à trouver un titre. Ça doit bien démontrer que
ce n'est pas clair dans ma tête. Pourtant l'exemple est assez simple est
parlant.
Depuis peu (sans doute après des mises à jour), j'ai un comportement qui
a légèrement changé.
J'ai un script1 (en bash) sur ma machine (gentoo), qui lance une
commande :
---------------------------- %< ------------------------------
ssh -x $DISTUSER@$HOST script_distant
---------------------------- %< ------------------------------
Jusqu'à ces derniers jours, l'ensemble me rendait la main juste après
l'affichage du echo, sans plus attendre.
Depuis, l'ensemble ne me rend la main qu'après le timeout de la commande
xcowsay (ligne 4), soit 60 secondes après.
Pourtant, la ligne 4: rend bien la main aussitôt, je l'ai vérifié. Si je
lance directement script_distant sur la machine distante, le script me
rend la main aussitôt. C'est quand je le lance par ssh que le
comportement change. Le script ne se termine pas tant que xcowsay est
affiché. Et ça, c'est nouveau.
Je ne souhaite pas mettre & à l'appel :
---------------------------- %< ------------------------------
ssh -x $DISTUSER@$HOST script_distant &
---------------------------- %< ------------------------------
parce que du coup, ça me rend la main immédiatement, avant même
l'affichage du echo (ici, je simplifie l'exemple, ça va plus loin qu'un
simple echo).
J'espère avoir été clair, mais j'en doute quand même un peu :)
Si vous avez un idée, une explication, ou mieux une solution, je vous en
remercie d'avance.
Christophe PEREZ , dans le message <o4sa13$955$, a écrit :
Je trouve que je me documente bien plus qu'un minimum. Mais il y a un moment où je juge qu'il faut rester raisonnable dans l'investissement.
L'apprentissage des principes de base de la gestion des processus est bien en deçà du seul du raisonnable.
Jo Engo
Le Sat, 07 Jan 2017 23:42:26 +0000, Christophe PEREZ a écrit :
Oui, oui, bien sûr, dans le cas général. Mais ici dans ce cas particulier sur ma machine unique avec bash juste aux fins de tests pour ce ng, cela me semblait acceptable.
En passant, et de mémoire, de plus sérieux que moi corrigeront : en voulant me débarrasser des sorties d'une commande verbeuse (ou les lire, je ne sais plus), les sorties n'étaient pas sur le descripteur 2 mais un autre => il y a au moins trois (3) «fichiers ouverts» et il ne suffit pas de fermer 1 et 2 pour éviter que ssh broute. -- La théorie est absurde dans la pratique et la pratique est aveugle sans la théorie. -+- Emmanuel Kant -+-
Le Sat, 07 Jan 2017 23:42:26 +0000, Christophe PEREZ a écrit :
Oui, oui, bien sûr, dans le cas général. Mais ici dans ce cas
particulier sur ma machine unique avec bash juste aux fins de tests pour
ce ng, cela me semblait acceptable.
En passant, et de mémoire, de plus sérieux que moi corrigeront :
en voulant me débarrasser des sorties d'une commande verbeuse (ou les
lire, je ne sais plus), les sorties n'étaient pas sur le descripteur 2
mais un autre => il y a au moins trois (3) «fichiers ouverts» et il ne
suffit pas de fermer 1 et 2 pour éviter que ssh broute.
--
La théorie est absurde dans la pratique et la pratique est aveugle sans
la théorie.
-+- Emmanuel Kant -+-
Le Sat, 07 Jan 2017 23:42:26 +0000, Christophe PEREZ a écrit :
Oui, oui, bien sûr, dans le cas général. Mais ici dans ce cas particulier sur ma machine unique avec bash juste aux fins de tests pour ce ng, cela me semblait acceptable.
En passant, et de mémoire, de plus sérieux que moi corrigeront : en voulant me débarrasser des sorties d'une commande verbeuse (ou les lire, je ne sais plus), les sorties n'étaient pas sur le descripteur 2 mais un autre => il y a au moins trois (3) «fichiers ouverts» et il ne suffit pas de fermer 1 et 2 pour éviter que ssh broute. -- La théorie est absurde dans la pratique et la pratique est aveugle sans la théorie. -+- Emmanuel Kant -+-
Christophe PEREZ
Le Sun, 08 Jan 2017 09:32:52 +0000, Jo Engo a écrit :
et il ne suffit pas de fermer 1 et 2 pour éviter que ssh broute.
stdin peut-être ? ce qui avec stdout et stderr fait bien 3 :)
Le Sun, 08 Jan 2017 09:32:52 +0000, Jo Engo a écrit :
et il ne suffit pas de fermer 1 et 2 pour éviter que ssh broute.
stdin peut-être ? ce qui avec stdout et stderr fait bien 3 :)
Le Sun, 08 Jan 2017 09:32:52 +0000, Jo Engo a écrit :
et il ne suffit pas de fermer 1 et 2 pour éviter que ssh broute.
stdin peut-être ? ce qui avec stdout et stderr fait bien 3 :)
Jo Engo
Le Sun, 08 Jan 2017 16:20:59 +0000, Christophe PEREZ a écrit :
stdin peut-être ? ce qui avec stdout et stderr fait bien 3
Sauf que stdin est ouvert en lecture seulement et les 2 autres en écriture seulement. -- Tous les hommes naissent comédiens, sauf quelques acteurs. -+- Sacha Guitry -+-
Le Sun, 08 Jan 2017 16:20:59 +0000, Christophe PEREZ a écrit :
stdin peut-être ? ce qui avec stdout et stderr fait bien 3
Sauf que stdin est ouvert en lecture seulement et les 2 autres en
écriture seulement.
--
Tous les hommes naissent comédiens, sauf quelques acteurs.
-+- Sacha Guitry -+-
Le Sun, 08 Jan 2017 16:20:59 +0000, Christophe PEREZ a écrit :
stdin peut-être ? ce qui avec stdout et stderr fait bien 3
Sauf que stdin est ouvert en lecture seulement et les 2 autres en écriture seulement. -- Tous les hommes naissent comédiens, sauf quelques acteurs. -+- Sacha Guitry -+-
Christophe PEREZ
Le Sun, 08 Jan 2017 18:20:49 +0000, Jo Engo a écrit :
Sauf que stdin est ouvert en lecture seulement et les 2 autres en écriture seulement.
Et ? Tu ne parlais pas d'ouverture en écriture mais de "fichiers ouverts" stdin est bien ouvert que je sache. Dans le cas contraire, j'attends avec curiosité que tu nommes le 3ème "fichier ouvert en écriture seulement" ;)
Le Sun, 08 Jan 2017 18:20:49 +0000, Jo Engo a écrit :
Sauf que stdin est ouvert en lecture seulement et les 2 autres en
écriture seulement.
Et ?
Tu ne parlais pas d'ouverture en écriture mais de "fichiers ouverts"
stdin est bien ouvert que je sache.
Dans le cas contraire, j'attends avec curiosité que tu nommes le 3ème
"fichier ouvert en écriture seulement" ;)
Le Sun, 08 Jan 2017 18:20:49 +0000, Jo Engo a écrit :
Sauf que stdin est ouvert en lecture seulement et les 2 autres en écriture seulement.
Et ? Tu ne parlais pas d'ouverture en écriture mais de "fichiers ouverts" stdin est bien ouvert que je sache. Dans le cas contraire, j'attends avec curiosité que tu nommes le 3ème "fichier ouvert en écriture seulement" ;)
Jo Engo
Le Sun, 08 Jan 2017 20:23:45 +0000, Christophe PEREZ a écrit :
Dans le cas contraire, j'attends avec curiosité que tu nommes le 3ème "fichier ouvert en écriture seulement"
Juste un retour d'expérience de n00b: $ blabla & je ne me rappelle pas la commande blabla ad lib. $ blabla 2>&1 >/dev/null blabla's not dead. Par contre pour trouver le nom du socket pour récupérer le blabla, je n'ai pas su, pourtant j'avais besoin. Les processus peuvent ouvrir autant de descripteur qu'ils veulent et les brancher sur tty. Si c'est le cas-là, voir la chaîne de commande, si l'une ne demande pas à causer sur tty, ce qui bloque ssh. -- Et ne te laisse pas avoir au super marché : il y a bien un rayon art ménager, mais ce n'est rien que du ready-made. -+- Noëlle, sur fr.rec.photo -+-
Le Sun, 08 Jan 2017 20:23:45 +0000, Christophe PEREZ a écrit :
Dans le cas contraire, j'attends avec curiosité que tu nommes le 3ème
"fichier ouvert en écriture seulement"
Juste un retour d'expérience de n00b:
$ blabla &
je ne me rappelle pas la commande
blabla ad lib.
$ blabla 2>&1 >/dev/null
blabla's not dead.
Par contre pour trouver le nom du socket pour récupérer le blabla, je
n'ai pas su, pourtant j'avais besoin.
Les processus peuvent ouvrir autant de descripteur qu'ils veulent et les
brancher sur tty. Si c'est le cas-là, voir la chaîne de commande, si
l'une ne demande pas à causer sur tty, ce qui bloque ssh.
--
Et ne te laisse pas avoir au super marché : il y a bien un rayon art
ménager, mais ce n'est rien que du ready-made.
-+- Noëlle, sur fr.rec.photo -+-
Le Sun, 08 Jan 2017 20:23:45 +0000, Christophe PEREZ a écrit :
Dans le cas contraire, j'attends avec curiosité que tu nommes le 3ème "fichier ouvert en écriture seulement"
Juste un retour d'expérience de n00b: $ blabla & je ne me rappelle pas la commande blabla ad lib. $ blabla 2>&1 >/dev/null blabla's not dead. Par contre pour trouver le nom du socket pour récupérer le blabla, je n'ai pas su, pourtant j'avais besoin. Les processus peuvent ouvrir autant de descripteur qu'ils veulent et les brancher sur tty. Si c'est le cas-là, voir la chaîne de commande, si l'une ne demande pas à causer sur tty, ce qui bloque ssh. -- Et ne te laisse pas avoir au super marché : il y a bien un rayon art ménager, mais ce n'est rien que du ready-made. -+- Noëlle, sur fr.rec.photo -+-
Nicolas George
Jo Engo , dans le message <58735941$0$5276$, a écrit :
$ blabla 2>&1 >/dev/null blabla's not dead.
Cette commande ne fait pas ce que tu crois. Les redirections ont lieu dans l'ordre, de gauche à droite (à l'exception de |, qui a lieu en tout premier). De fait : ~ $ ls /etc/passwd /etc/rien 2>&1 > /dev/null ls: cannot access '/etc/rien': No such file or directory
Jo Engo , dans le message <58735941$0$5276$426a74cc@news.free.fr>, a
écrit :
$ blabla 2>&1 >/dev/null
blabla's not dead.
Cette commande ne fait pas ce que tu crois. Les redirections ont lieu
dans l'ordre, de gauche à droite (à l'exception de |, qui a lieu en tout
premier). De fait :
~ $ ls /etc/passwd /etc/rien 2>&1 > /dev/null
ls: cannot access '/etc/rien': No such file or directory
Jo Engo , dans le message <58735941$0$5276$, a écrit :
$ blabla 2>&1 >/dev/null blabla's not dead.
Cette commande ne fait pas ce que tu crois. Les redirections ont lieu dans l'ordre, de gauche à droite (à l'exception de |, qui a lieu en tout premier). De fait : ~ $ ls /etc/passwd /etc/rien 2>&1 > /dev/null ls: cannot access '/etc/rien': No such file or directory
Doug713705
Le 09-01-2017, Jo Engo nous expliquait dans fr.comp.os.linux.configuration (<58735941$0$5276$) :
Les processus peuvent ouvrir autant de descripteur qu'ils veulent et les brancher sur tty.
Pas tout à fait, il existe une limite du nombre de FD ouverts simultanément au niveau noyau: cat /proc/sys/fs/file-max 203182 Là dessus s'ajoutent les limites liées à l'utilisateur: Limite "hard" que l'utilisateur (hors superuser) ne pourra en aucun cas modifier. :~$ ulimit -Hn 4096 Limite "soft" que l'utilisateur peut régler sans pour autant outrepasser la limite "hard": :~$ ulimit -Hs unlimited 'unlimited' est donc ici équivalent à 4096. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
Le 09-01-2017, Jo Engo nous expliquait dans
fr.comp.os.linux.configuration
(<58735941$0$5276$426a74cc@news.free.fr>) :
Les processus peuvent ouvrir autant de descripteur qu'ils veulent et les
brancher sur tty.
Pas tout à fait, il existe une limite du nombre de FD ouverts
simultanément au niveau noyau:
cat /proc/sys/fs/file-max
203182
Là dessus s'ajoutent les limites liées à l'utilisateur:
Limite "hard" que l'utilisateur (hors superuser) ne pourra en aucun cas modifier.
doug@golgoth31:~$ ulimit -Hn
4096
Limite "soft" que l'utilisateur peut régler sans pour autant outrepasser la
limite "hard":
doug@golgoth31:~$ ulimit -Hs
unlimited
'unlimited' est donc ici équivalent à 4096.
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Le 09-01-2017, Jo Engo nous expliquait dans fr.comp.os.linux.configuration (<58735941$0$5276$) :
Les processus peuvent ouvrir autant de descripteur qu'ils veulent et les brancher sur tty.
Pas tout à fait, il existe une limite du nombre de FD ouverts simultanément au niveau noyau: cat /proc/sys/fs/file-max 203182 Là dessus s'ajoutent les limites liées à l'utilisateur: Limite "hard" que l'utilisateur (hors superuser) ne pourra en aucun cas modifier. :~$ ulimit -Hn 4096 Limite "soft" que l'utilisateur peut régler sans pour autant outrepasser la limite "hard": :~$ ulimit -Hs unlimited 'unlimited' est donc ici équivalent à 4096. -- Je ne connaîtrai rien de tes habitudes Il se peut même que tu sois décédée Mais j'demanderai ta main pour la couper -- H.F. Thiéfaine, L'ascenceur de 22H43
