je me demandais ce que devais une session lorsque la fenetre putty
etais planté ?
souvent je lance de gros travaux a faire, et mon amie comprenant ce
qu'est putty vient fermer la fenetre,
est ce que la tache continue tout de meme jusqu'a la fin ou est il
interrompu ?
dans ce cas la quoi faire pour lancer une tache jusqu'a son terme ?
sinon comment reprendre une tache qui etait en cours ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Manuel Bouyer
sylvain pham wrote:
bonjour,
je me demandais ce que devais une session lorsque la fenetre putty etais planté ? souvent je lance de gros travaux a faire, et mon amie comprenant ce qu'est putty vient fermer la fenetre,
est ce que la tache continue tout de meme jusqu'a la fin ou est il interrompu ?
Je dirais que ca depend comment la tache gere SIGUP, mais le comportement par defaut c'est la fin de la tache.
dans ce cas la quoi faire pour lancer une tache jusqu'a son terme ?
nohup la_tache -avec -ses -arguments
sinon comment reprendre une tache qui etait en cours ?
A priori c'est pas possible. Par contre tu peux regarder un outil genre screen. Ca permet de lancer des taches dans un terminal virtuel, deconnecter le terminal reel, et se reconnecter au terminal virtuel depuis un autre.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
sylvain pham <sylvain_pham@hotmail.com> wrote:
bonjour,
je me demandais ce que devais une session lorsque la fenetre putty
etais planté ?
souvent je lance de gros travaux a faire, et mon amie comprenant ce
qu'est putty vient fermer la fenetre,
est ce que la tache continue tout de meme jusqu'a la fin ou est il
interrompu ?
Je dirais que ca depend comment la tache gere SIGUP, mais le comportement
par defaut c'est la fin de la tache.
dans ce cas la quoi faire pour lancer une tache jusqu'a son terme ?
nohup la_tache -avec -ses -arguments
sinon comment reprendre une tache qui etait en cours ?
A priori c'est pas possible.
Par contre tu peux regarder un outil genre screen.
Ca permet de lancer des taches dans un terminal virtuel, deconnecter le
terminal reel, et se reconnecter au terminal virtuel depuis un autre.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 24 ans d'experience feront toujours la difference
--
je me demandais ce que devais une session lorsque la fenetre putty etais planté ? souvent je lance de gros travaux a faire, et mon amie comprenant ce qu'est putty vient fermer la fenetre,
est ce que la tache continue tout de meme jusqu'a la fin ou est il interrompu ?
Je dirais que ca depend comment la tache gere SIGUP, mais le comportement par defaut c'est la fin de la tache.
dans ce cas la quoi faire pour lancer une tache jusqu'a son terme ?
nohup la_tache -avec -ses -arguments
sinon comment reprendre une tache qui etait en cours ?
A priori c'est pas possible. Par contre tu peux regarder un outil genre screen. Ca permet de lancer des taches dans un terminal virtuel, deconnecter le terminal reel, et se reconnecter au terminal virtuel depuis un autre.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
pornin
According to Xavier :
Pour ma part, j'ai jamais pigé comment ça marche.
Idéalement, il faut lire "Advanced Programming in the UNIX(r) Environment" de W. Richard Stevens. Le chapitre 9 décrit les histoires de "process group" et "controlling terminal" ; le chapitre 19 décrit les pseudo-terminaux. Le reste du livre est très bien aussi, et je le recommande chaudement à toute personne voulant faire sereinement de la programmation sous Unix.
Pour faire simple :
Quand on a un file descriptor, on peut faire des read() et des write() dessus. Ce qu'il advient dépend de ce sur quoi ce file descriptor est branché. Si c'est un fichier, ça fait des lectures et des écritures dans le fichier. Si c'est une socket, ça lit et écrit des octets sur réseau. Ça peut être aussi un terminal, qui est une sorte de portail sur "quelque chose qui ressemble à un écran en mode texte". On peut lire et écrire des octets sur un terminal, et on peut aussi utiliser quelques fonctions annexes (tcgetattr(),...) pour obtenir la taille du terminal (nombre de colonnes et de lignes) et changer certains paramètres (echo ou pas echo, caractère envoyé par backspace, etc...).
Sur la machine, il y a de vrais terminaux, par exemple les consoles texte. Les processus voient un terminal, et le noyau transcrit les accès à ce terminal en des affichages vidéo. Il y a aussi des pseudo-terminaux : un pseudo-terminal, c'est une émulation de terminal avec un "contrôleur". Par exemple, /dev/ttyp0 est un pseudo-terminal, et le contrôleur est /dev/ptyp0. Un programme ouvrant /dev/ttyp0 parle dans un terminal ; un autre programme ouvrant /dev/ptyp0 se place de l'autre côté de l'écran : ce que le premier programme écrit dans /dev/ttyp0, le second programme le lit dans /dev/ptyp0, et réciproquement. Par ailleurs, le second programme dit à /dev/ptyp0 quelle taille il doit avoir et le premier programme lit cette taille depuis /dev/ttyp0.
Un programme comme xterm, ou sshd, utilise un pseudo-terminal. Le shell et les programmes lancés dans le shell sont branchés sur un pseudo-terminal ; le xterm/sshd gère le contrôleur du pseudo-terminal, et traduit ce qui se passe sur le terminal en, respectivement, des commandes X11 (échangés avec le serveur X, pour lire des frappes de touches de clavier et écrire des caractères) ou des paquets de données envoyées dans la connexion SSH.
"screen" agit comme un xterm en mode texte : il est lancé dans un terminal et contrôle un autre pseudo-terminal, dans lequel il lance un shell. Ensuite, screen fait la liaison entre le pseudo-terminal qu'il contrôle et le terminal dans lequel il tourne. L'avantage de screen, c'est qu'on peut lui demander de ne plus faire cette liaison : quand on demande de se "détacher", screen rompt tous les liens avec le terminal dans lequel il tourne, et part vivre sa vie dans son coin. Mais les processus lancés dans le screen ne voient rien de cela : il parlent avec le pseudo-terminal contrôlé par screen, et continuent à la faire. En passant, screen peut en fait contrôler plusieurs pseudo-terminaux, et gérer ainsi un multi-console. Comme par ailleurs screen fait tout la liaison entre les pseudo-terminaux qu'il contrôle et le terminal dans lequel il tourne, screen peut faire des finasseries : émuler un type de terminal différent, faire des screenshots, garder en mémoire du "scrollback", faire du copy-paste au clavier...
"nohup" est beaucoup plus limité. Là, c'est pour uniquement résister à la mort des terminaux et du shell qui a lancé le truc. En gros, quand un shell interactif (qui tourne dans un terminal) lance un processus, ledit processus est relié à la fois au shell et au terminal. Quand un terminal disparaît et que c'était le terminal de contrôle d'un processus, le processus se prend un SIGHUP. Par ailleurs, quand son "session leader" meurt (en général, le "session leader" c'est le shell interactif), il se prend aussi un SIGHUP. Le boulot de nohup, c'est d'intercepter le SIGHUP et de le mépriser ; comme ça, le processus lancé par nohup ne voit pas ce signal (habituellement léthal). Par ailleurs, nohup s'occupe de rediriger les sorties du programme (stdout et stderr, pour faire simple) dans nohup.out (sauf si on les redirige déjà ailleurs que dans un terminal), comme ça le programme peut continuer à pondre des données après la mort du terminal.
On peut demander à certains shells (zsh) de faire le boulot d'interception du SIGHUP (setopt nohup) et alors se passer de nohup (il suffit de faire les redirections). La solution la plus générale reste screen (surtout pour garder en arrière-plan des processus qui veulent un terminal et pas seulement un fichier -- au hasard, un éditeur de textes).
--Thomas Pornin
According to Xavier <xavier@groumpf.org>:
Pour ma part, j'ai jamais pigé comment ça marche.
Idéalement, il faut lire "Advanced Programming in the UNIX(r)
Environment" de W. Richard Stevens. Le chapitre 9 décrit les histoires
de "process group" et "controlling terminal" ; le chapitre 19 décrit
les pseudo-terminaux. Le reste du livre est très bien aussi, et je le
recommande chaudement à toute personne voulant faire sereinement de la
programmation sous Unix.
Pour faire simple :
Quand on a un file descriptor, on peut faire des read() et des write()
dessus. Ce qu'il advient dépend de ce sur quoi ce file descriptor est
branché. Si c'est un fichier, ça fait des lectures et des écritures
dans le fichier. Si c'est une socket, ça lit et écrit des octets sur
réseau. Ça peut être aussi un terminal, qui est une sorte de portail sur
"quelque chose qui ressemble à un écran en mode texte". On peut lire et
écrire des octets sur un terminal, et on peut aussi utiliser quelques
fonctions annexes (tcgetattr(),...) pour obtenir la taille du terminal
(nombre de colonnes et de lignes) et changer certains paramètres (echo
ou pas echo, caractère envoyé par backspace, etc...).
Sur la machine, il y a de vrais terminaux, par exemple les consoles
texte. Les processus voient un terminal, et le noyau transcrit
les accès à ce terminal en des affichages vidéo. Il y a aussi des
pseudo-terminaux : un pseudo-terminal, c'est une émulation de terminal
avec un "contrôleur". Par exemple, /dev/ttyp0 est un pseudo-terminal, et
le contrôleur est /dev/ptyp0. Un programme ouvrant /dev/ttyp0 parle dans
un terminal ; un autre programme ouvrant /dev/ptyp0 se place de l'autre
côté de l'écran : ce que le premier programme écrit dans /dev/ttyp0,
le second programme le lit dans /dev/ptyp0, et réciproquement. Par
ailleurs, le second programme dit à /dev/ptyp0 quelle taille il doit
avoir et le premier programme lit cette taille depuis /dev/ttyp0.
Un programme comme xterm, ou sshd, utilise un pseudo-terminal. Le
shell et les programmes lancés dans le shell sont branchés sur un
pseudo-terminal ; le xterm/sshd gère le contrôleur du pseudo-terminal,
et traduit ce qui se passe sur le terminal en, respectivement, des
commandes X11 (échangés avec le serveur X, pour lire des frappes de
touches de clavier et écrire des caractères) ou des paquets de données
envoyées dans la connexion SSH.
"screen" agit comme un xterm en mode texte : il est lancé dans un
terminal et contrôle un autre pseudo-terminal, dans lequel il lance un
shell. Ensuite, screen fait la liaison entre le pseudo-terminal qu'il
contrôle et le terminal dans lequel il tourne. L'avantage de screen,
c'est qu'on peut lui demander de ne plus faire cette liaison : quand on
demande de se "détacher", screen rompt tous les liens avec le terminal
dans lequel il tourne, et part vivre sa vie dans son coin. Mais les
processus lancés dans le screen ne voient rien de cela : il parlent
avec le pseudo-terminal contrôlé par screen, et continuent à la faire.
En passant, screen peut en fait contrôler plusieurs pseudo-terminaux,
et gérer ainsi un multi-console. Comme par ailleurs screen fait tout
la liaison entre les pseudo-terminaux qu'il contrôle et le terminal
dans lequel il tourne, screen peut faire des finasseries : émuler un
type de terminal différent, faire des screenshots, garder en mémoire du
"scrollback", faire du copy-paste au clavier...
"nohup" est beaucoup plus limité. Là, c'est pour uniquement résister à
la mort des terminaux et du shell qui a lancé le truc. En gros, quand un
shell interactif (qui tourne dans un terminal) lance un processus, ledit
processus est relié à la fois au shell et au terminal. Quand un terminal
disparaît et que c'était le terminal de contrôle d'un processus, le
processus se prend un SIGHUP. Par ailleurs, quand son "session leader"
meurt (en général, le "session leader" c'est le shell interactif), il
se prend aussi un SIGHUP. Le boulot de nohup, c'est d'intercepter le
SIGHUP et de le mépriser ; comme ça, le processus lancé par nohup ne
voit pas ce signal (habituellement léthal). Par ailleurs, nohup s'occupe
de rediriger les sorties du programme (stdout et stderr, pour faire
simple) dans nohup.out (sauf si on les redirige déjà ailleurs que dans
un terminal), comme ça le programme peut continuer à pondre des données
après la mort du terminal.
On peut demander à certains shells (zsh) de faire le boulot
d'interception du SIGHUP (setopt nohup) et alors se passer de nohup (il
suffit de faire les redirections). La solution la plus générale reste
screen (surtout pour garder en arrière-plan des processus qui veulent
un terminal et pas seulement un fichier -- au hasard, un éditeur de
textes).
Idéalement, il faut lire "Advanced Programming in the UNIX(r) Environment" de W. Richard Stevens. Le chapitre 9 décrit les histoires de "process group" et "controlling terminal" ; le chapitre 19 décrit les pseudo-terminaux. Le reste du livre est très bien aussi, et je le recommande chaudement à toute personne voulant faire sereinement de la programmation sous Unix.
Pour faire simple :
Quand on a un file descriptor, on peut faire des read() et des write() dessus. Ce qu'il advient dépend de ce sur quoi ce file descriptor est branché. Si c'est un fichier, ça fait des lectures et des écritures dans le fichier. Si c'est une socket, ça lit et écrit des octets sur réseau. Ça peut être aussi un terminal, qui est une sorte de portail sur "quelque chose qui ressemble à un écran en mode texte". On peut lire et écrire des octets sur un terminal, et on peut aussi utiliser quelques fonctions annexes (tcgetattr(),...) pour obtenir la taille du terminal (nombre de colonnes et de lignes) et changer certains paramètres (echo ou pas echo, caractère envoyé par backspace, etc...).
Sur la machine, il y a de vrais terminaux, par exemple les consoles texte. Les processus voient un terminal, et le noyau transcrit les accès à ce terminal en des affichages vidéo. Il y a aussi des pseudo-terminaux : un pseudo-terminal, c'est une émulation de terminal avec un "contrôleur". Par exemple, /dev/ttyp0 est un pseudo-terminal, et le contrôleur est /dev/ptyp0. Un programme ouvrant /dev/ttyp0 parle dans un terminal ; un autre programme ouvrant /dev/ptyp0 se place de l'autre côté de l'écran : ce que le premier programme écrit dans /dev/ttyp0, le second programme le lit dans /dev/ptyp0, et réciproquement. Par ailleurs, le second programme dit à /dev/ptyp0 quelle taille il doit avoir et le premier programme lit cette taille depuis /dev/ttyp0.
Un programme comme xterm, ou sshd, utilise un pseudo-terminal. Le shell et les programmes lancés dans le shell sont branchés sur un pseudo-terminal ; le xterm/sshd gère le contrôleur du pseudo-terminal, et traduit ce qui se passe sur le terminal en, respectivement, des commandes X11 (échangés avec le serveur X, pour lire des frappes de touches de clavier et écrire des caractères) ou des paquets de données envoyées dans la connexion SSH.
"screen" agit comme un xterm en mode texte : il est lancé dans un terminal et contrôle un autre pseudo-terminal, dans lequel il lance un shell. Ensuite, screen fait la liaison entre le pseudo-terminal qu'il contrôle et le terminal dans lequel il tourne. L'avantage de screen, c'est qu'on peut lui demander de ne plus faire cette liaison : quand on demande de se "détacher", screen rompt tous les liens avec le terminal dans lequel il tourne, et part vivre sa vie dans son coin. Mais les processus lancés dans le screen ne voient rien de cela : il parlent avec le pseudo-terminal contrôlé par screen, et continuent à la faire. En passant, screen peut en fait contrôler plusieurs pseudo-terminaux, et gérer ainsi un multi-console. Comme par ailleurs screen fait tout la liaison entre les pseudo-terminaux qu'il contrôle et le terminal dans lequel il tourne, screen peut faire des finasseries : émuler un type de terminal différent, faire des screenshots, garder en mémoire du "scrollback", faire du copy-paste au clavier...
"nohup" est beaucoup plus limité. Là, c'est pour uniquement résister à la mort des terminaux et du shell qui a lancé le truc. En gros, quand un shell interactif (qui tourne dans un terminal) lance un processus, ledit processus est relié à la fois au shell et au terminal. Quand un terminal disparaît et que c'était le terminal de contrôle d'un processus, le processus se prend un SIGHUP. Par ailleurs, quand son "session leader" meurt (en général, le "session leader" c'est le shell interactif), il se prend aussi un SIGHUP. Le boulot de nohup, c'est d'intercepter le SIGHUP et de le mépriser ; comme ça, le processus lancé par nohup ne voit pas ce signal (habituellement léthal). Par ailleurs, nohup s'occupe de rediriger les sorties du programme (stdout et stderr, pour faire simple) dans nohup.out (sauf si on les redirige déjà ailleurs que dans un terminal), comme ça le programme peut continuer à pondre des données après la mort du terminal.
On peut demander à certains shells (zsh) de faire le boulot d'interception du SIGHUP (setopt nohup) et alors se passer de nohup (il suffit de faire les redirections). La solution la plus générale reste screen (surtout pour garder en arrière-plan des processus qui veulent un terminal et pas seulement un fichier -- au hasard, un éditeur de textes).
--Thomas Pornin
Maxime Ritter
Le Thu, 23 Oct 2003 00:18:14 +0200, dans fr.comp.os.bsd, Xavier a dit :
man screen Pour ma part, j'ai jamais pigé comment ça marche.
Et pourtant, l'essayer c'est l'adopter ! screen en quelques mots (tout l'inverse du man) :
screen pour lancer la session, et ouvrir le premier terminal virtuel (sauf si le .screenrc est configure differemment ce que je ne sais pas faire) CTRL-A d pour 'détacher' screen (sans quitter ce que l'on fait) screen -dr pour récupérer Pour quitter screen, suffit de quitter tous les terminaux...
CTRL-A c pour créer un nouveeau terminal CTRL-A " pour changer de terminal CTRL-A numéro (0, 1, 2, etc..) pour aller directement a un autre terminal
CTRL-A ? pour l'aide.
Après il y a des d'autres fonctions, mais voila pour la base.
-- Maxime Ritter | French Computer Geek Mail : | http://maxime.ritter.eu.org
Le Thu, 23 Oct 2003 00:18:14 +0200, dans fr.comp.os.bsd, Xavier a dit :
man screen
Pour ma part, j'ai jamais pigé comment ça marche.
Et pourtant, l'essayer c'est l'adopter !
screen en quelques mots (tout l'inverse du man) :
screen pour lancer la session, et ouvrir le premier terminal virtuel (sauf
si le .screenrc est configure differemment ce que je ne sais pas faire)
CTRL-A d pour 'détacher' screen (sans quitter ce que l'on fait)
screen -dr pour récupérer
Pour quitter screen, suffit de quitter tous les terminaux...
CTRL-A c pour créer un nouveeau terminal
CTRL-A " pour changer de terminal
CTRL-A numéro (0, 1, 2, etc..) pour aller directement a un autre terminal
CTRL-A ? pour l'aide.
Après il y a des d'autres fonctions, mais voila pour la base.
--
Maxime Ritter | French Computer Geek
Mail : mritter@alussinan.org | http://maxime.ritter.eu.org
Le Thu, 23 Oct 2003 00:18:14 +0200, dans fr.comp.os.bsd, Xavier a dit :
man screen Pour ma part, j'ai jamais pigé comment ça marche.
Et pourtant, l'essayer c'est l'adopter ! screen en quelques mots (tout l'inverse du man) :
screen pour lancer la session, et ouvrir le premier terminal virtuel (sauf si le .screenrc est configure differemment ce que je ne sais pas faire) CTRL-A d pour 'détacher' screen (sans quitter ce que l'on fait) screen -dr pour récupérer Pour quitter screen, suffit de quitter tous les terminaux...
CTRL-A c pour créer un nouveeau terminal CTRL-A " pour changer de terminal CTRL-A numéro (0, 1, 2, etc..) pour aller directement a un autre terminal
CTRL-A ? pour l'aide.
Après il y a des d'autres fonctions, mais voila pour la base.
-- Maxime Ritter | French Computer Geek Mail : | http://maxime.ritter.eu.org
sylvain_pham
screen pour lancer la session, et ouvrir le premier terminal virtuel (sauf si le .screenrc est configure differemment ce que je ne sais pas faire) CTRL-A d pour 'détacher' screen (sans quitter ce que l'on fait) screen -dr pour récupérer Pour quitter screen, suffit de quitter tous les terminaux...
CTRL-A c pour créer un nouveeau terminal CTRL-A " pour changer de terminal CTRL-A numéro (0, 1, 2, etc..) pour aller directement a un autre terminal
CTRL-A ? pour l'aide.
Après il y a des d'autres fonctions, mais voila pour la base.
Un grands merci pour tous les deux.
Sylvain
screen pour lancer la session, et ouvrir le premier terminal virtuel (sauf
si le .screenrc est configure differemment ce que je ne sais pas faire)
CTRL-A d pour 'détacher' screen (sans quitter ce que l'on fait)
screen -dr pour récupérer
Pour quitter screen, suffit de quitter tous les terminaux...
CTRL-A c pour créer un nouveeau terminal
CTRL-A " pour changer de terminal
CTRL-A numéro (0, 1, 2, etc..) pour aller directement a un autre terminal
CTRL-A ? pour l'aide.
Après il y a des d'autres fonctions, mais voila pour la base.
screen pour lancer la session, et ouvrir le premier terminal virtuel (sauf si le .screenrc est configure differemment ce que je ne sais pas faire) CTRL-A d pour 'détacher' screen (sans quitter ce que l'on fait) screen -dr pour récupérer Pour quitter screen, suffit de quitter tous les terminaux...
CTRL-A c pour créer un nouveeau terminal CTRL-A " pour changer de terminal CTRL-A numéro (0, 1, 2, etc..) pour aller directement a un autre terminal
CTRL-A ? pour l'aide.
Après il y a des d'autres fonctions, mais voila pour la base.
