Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
Question de néophyte : on fait comment avec screen pour lancer un prog, fermer le shell avec le prog qui continue à tourner en tâche de fond, et le récupérer plus tard dans une autre session ?
RTFM, tu connais ?
Oui, il connait.
"man screen" est ton ami.
Je cite l'OP :
[ moi]$ man screen Il n'y a pas de page de manuel pour screen.
Pour une fois qu'un utilisateur a le bon réflexe, il est dommage de lui balancer un RTFM. ;-P
-- Sébastien Monbrun aka TiChou
Dans le message <news:pan.2006.05.05.08.15.21.462273@imaginet.fr>,
*Emmanuel Florac* tapota sur f.c.o.l.configuration :
Question de néophyte :
on fait comment avec screen pour lancer un prog, fermer le shell avec le
prog qui continue à tourner en tâche de fond, et le récupérer plus
tard dans une autre session ?
RTFM, tu connais ?
Oui, il connait.
"man screen" est ton ami.
Je cite l'OP :
[moi@Linux2 moi]$ man screen
Il n'y a pas de page de manuel pour screen.
Pour une fois qu'un utilisateur a le bon réflexe, il est dommage de lui
balancer un RTFM. ;-P
Dans le message <news:, *Emmanuel Florac* tapota sur f.c.o.l.configuration :
Question de néophyte : on fait comment avec screen pour lancer un prog, fermer le shell avec le prog qui continue à tourner en tâche de fond, et le récupérer plus tard dans une autre session ?
RTFM, tu connais ?
Oui, il connait.
"man screen" est ton ami.
Je cite l'OP :
[ moi]$ man screen Il n'y a pas de page de manuel pour screen.
Pour une fois qu'un utilisateur a le bon réflexe, il est dommage de lui balancer un RTFM. ;-P
-- Sébastien Monbrun aka TiChou
Sébastien Kirche
Le 4 May 2006 à 22:32, Nicolas George vraute :
nohup est une connerie, c'est setsid qu'il faut utiliser.
Tu pourrais un peu développer stp ? Je ne doute pas de tes compétences supérieures aux miennes, mais disons que formulé comme cela, ça semble un peu péremptoire :)
Pour ce que je vois dans le manuel : nohup - run a command immune to hangups, with output to a non-tty setsid - run a program in a new session
Pour ce que j'en sais pour l'utiliser parfois nohup fonctionne, puisqu'il permet à un process de survivre à la fermeture du xterm depuis lequel il a été lancé. Au hasard, un programme doté d'une interface graphique.
-- Sébastien Kirche
Le 4 May 2006 à 22:32, Nicolas George vraute :
nohup est une connerie, c'est setsid qu'il faut utiliser.
Tu pourrais un peu développer stp ?
Je ne doute pas de tes compétences supérieures aux miennes, mais disons
que formulé comme cela, ça semble un peu péremptoire :)
Pour ce que je vois dans le manuel :
nohup - run a command immune to hangups, with output to a non-tty
setsid - run a program in a new session
Pour ce que j'en sais pour l'utiliser parfois nohup fonctionne,
puisqu'il permet à un process de survivre à la fermeture du xterm depuis
lequel il a été lancé. Au hasard, un programme doté d'une interface
graphique.
nohup est une connerie, c'est setsid qu'il faut utiliser.
Tu pourrais un peu développer stp ? Je ne doute pas de tes compétences supérieures aux miennes, mais disons que formulé comme cela, ça semble un peu péremptoire :)
Pour ce que je vois dans le manuel : nohup - run a command immune to hangups, with output to a non-tty setsid - run a program in a new session
Pour ce que j'en sais pour l'utiliser parfois nohup fonctionne, puisqu'il permet à un process de survivre à la fermeture du xterm depuis lequel il a été lancé. Au hasard, un programme doté d'une interface graphique.
-- Sébastien Kirche
Nicolas George
Sébastien Kirche wrote in message :
Tu pourrais un peu développer stp ? Je ne doute pas de tes compétences supérieures aux miennes, mais disons que formulé comme cela, ça semble un peu péremptoire :)
Pour ce que je vois dans le manuel : nohup - run a command immune to hangups, with output to a non-tty setsid - run a program in a new session
Pour détacher un processus d'un terminal, il y a plusieurs choses à faire :
(1) s'assurer que ses entrées-sorties ne sont pas sur le terminal ;
(2) faire comprendre au shell que ce processus est en arrière plan ;
(3) lui faire perdre son terminal de contrôle.
nohup fait le (1), mais c'est absolument inutile, parce que ça se fait aussi bien explicitement avec quelque chose du style :
foo < /dev/null > foo.log 2>&1
nohup ne fait pas le (2) ; mais là encore c'est inutile, puisque c'est le rôle du & du shell (et éventuellement de disown, ou de &!, si le shell fait du job control agressif).
nohup ne fait pas le (3), à la place, il règle le processus de manière à le protéger contre les effets de ne pas avoir fait le (3), à savoir se prendre un SIGHUP quand le terminal de contrôle est fermé, ce qui normalement tue le processus. C'est là qu'est la connerie, parce que :
- ça donnera des affichages qui ne sont pas bons dans la liste des processus (c'est bénin) ;
- il peut se trouver des circonstances où cette protection se perd, ce qui fait que le processus se fait quand même tuer ;
- du point de vue du terminal de contôle, le processus est toujours attaché, ce qui interdit la libération des resources correspondantes.
Pour illustrer le dernier point, on peut citer certaines versions de SSH qui ne terminent pas proprement la session tant qu'un processus est attaché au terminal, même s'il n'y a aucun file descriptor ouvert.
setsid fait (3), c'est fondamentalement sa raison d'être (setsid, c'est *l*'appel système qui sert précisément à détacher un processus d'un terminal de contrôle). Un corollaire immédiat de son fonctionnement est qu'il fait (2) également. Il n'y a que (1) à faire à la main ; ça peut s'automatiser avec une fonction shell.
Sébastien Kirche
wrote in message <87slnow5x8.fsf@petisuix.seki.fr>:
Tu pourrais un peu développer stp ?
Je ne doute pas de tes compétences supérieures aux miennes, mais disons
que formulé comme cela, ça semble un peu péremptoire :)
Pour ce que je vois dans le manuel :
nohup - run a command immune to hangups, with output to a non-tty
setsid - run a program in a new session
Pour détacher un processus d'un terminal, il y a plusieurs choses à faire :
(1) s'assurer que ses entrées-sorties ne sont pas sur le terminal ;
(2) faire comprendre au shell que ce processus est en arrière plan ;
(3) lui faire perdre son terminal de contrôle.
nohup fait le (1), mais c'est absolument inutile, parce que ça se fait aussi
bien explicitement avec quelque chose du style :
foo < /dev/null > foo.log 2>&1
nohup ne fait pas le (2) ; mais là encore c'est inutile, puisque c'est le
rôle du & du shell (et éventuellement de disown, ou de &!, si le shell fait
du job control agressif).
nohup ne fait pas le (3), à la place, il règle le processus de manière à le
protéger contre les effets de ne pas avoir fait le (3), à savoir se prendre
un SIGHUP quand le terminal de contrôle est fermé, ce qui normalement tue le
processus. C'est là qu'est la connerie, parce que :
- ça donnera des affichages qui ne sont pas bons dans la liste des processus
(c'est bénin) ;
- il peut se trouver des circonstances où cette protection se perd, ce qui
fait que le processus se fait quand même tuer ;
- du point de vue du terminal de contôle, le processus est toujours attaché,
ce qui interdit la libération des resources correspondantes.
Pour illustrer le dernier point, on peut citer certaines versions de SSH qui
ne terminent pas proprement la session tant qu'un processus est attaché au
terminal, même s'il n'y a aucun file descriptor ouvert.
setsid fait (3), c'est fondamentalement sa raison d'être (setsid, c'est
*l*'appel système qui sert précisément à détacher un processus d'un terminal
de contrôle). Un corollaire immédiat de son fonctionnement est qu'il fait
(2) également. Il n'y a que (1) à faire à la main ; ça peut s'automatiser
avec une fonction shell.
Tu pourrais un peu développer stp ? Je ne doute pas de tes compétences supérieures aux miennes, mais disons que formulé comme cela, ça semble un peu péremptoire :)
Pour ce que je vois dans le manuel : nohup - run a command immune to hangups, with output to a non-tty setsid - run a program in a new session
Pour détacher un processus d'un terminal, il y a plusieurs choses à faire :
(1) s'assurer que ses entrées-sorties ne sont pas sur le terminal ;
(2) faire comprendre au shell que ce processus est en arrière plan ;
(3) lui faire perdre son terminal de contrôle.
nohup fait le (1), mais c'est absolument inutile, parce que ça se fait aussi bien explicitement avec quelque chose du style :
foo < /dev/null > foo.log 2>&1
nohup ne fait pas le (2) ; mais là encore c'est inutile, puisque c'est le rôle du & du shell (et éventuellement de disown, ou de &!, si le shell fait du job control agressif).
nohup ne fait pas le (3), à la place, il règle le processus de manière à le protéger contre les effets de ne pas avoir fait le (3), à savoir se prendre un SIGHUP quand le terminal de contrôle est fermé, ce qui normalement tue le processus. C'est là qu'est la connerie, parce que :
- ça donnera des affichages qui ne sont pas bons dans la liste des processus (c'est bénin) ;
- il peut se trouver des circonstances où cette protection se perd, ce qui fait que le processus se fait quand même tuer ;
- du point de vue du terminal de contôle, le processus est toujours attaché, ce qui interdit la libération des resources correspondantes.
Pour illustrer le dernier point, on peut citer certaines versions de SSH qui ne terminent pas proprement la session tant qu'un processus est attaché au terminal, même s'il n'y a aucun file descriptor ouvert.
setsid fait (3), c'est fondamentalement sa raison d'être (setsid, c'est *l*'appel système qui sert précisément à détacher un processus d'un terminal de contrôle). Un corollaire immédiat de son fonctionnement est qu'il fait (2) également. Il n'y a que (1) à faire à la main ; ça peut s'automatiser avec une fonction shell.
Sébastien Kirche
Le 5 May 2006 à 23:48, Nicolas George vraute :
Pour détacher un processus d'un terminal, il y a plusieurs choses à faire :
Voilà ! Merci pour ce point de technique que je m'empresse de mettre de côté :)
-- Sébastien Kirche
Le 5 May 2006 à 23:48, Nicolas George vraute :
Pour détacher un processus d'un terminal, il y a plusieurs choses à
faire :
Voilà ! Merci pour ce point de technique que je m'empresse de mettre de
côté :)
