> Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
> Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
> Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
Bulot gregory a écrit :Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
Ca ne peut pas marcher car la fermeture de session va tuer le shell qui
va envoyer le signal HUP à tous ses fils. C'est pourquoi il existe la
commande "nohup" pour executer un process en indiquant qu'il ne doit pas
recevoir ce signal :
nohup commande &
Par contre, une fois le processus lancé, je ne sais pas s'il est
possible de bloquer le signal. Il faut certainement consulter l'aide de
ton shell en recherchant les commandes de gestion des Táches (commandes
jobs, fg, bg ... sous bash). Tu y trouveras peut etre ton bonheur.
Fanfan
Bulot gregory a écrit :
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
Ca ne peut pas marcher car la fermeture de session va tuer le shell qui
va envoyer le signal HUP à tous ses fils. C'est pourquoi il existe la
commande "nohup" pour executer un process en indiquant qu'il ne doit pas
recevoir ce signal :
nohup commande &
Par contre, une fois le processus lancé, je ne sais pas s'il est
possible de bloquer le signal. Il faut certainement consulter l'aide de
ton shell en recherchant les commandes de gestion des Táches (commandes
jobs, fg, bg ... sous bash). Tu y trouveras peut etre ton bonheur.
Fanfan
Bulot gregory a écrit :Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le process
tourne toujours (ps -aef ?)
Ca ne peut pas marcher car la fermeture de session va tuer le shell qui
va envoyer le signal HUP à tous ses fils. C'est pourquoi il existe la
commande "nohup" pour executer un process en indiquant qu'il ne doit pas
recevoir ce signal :
nohup commande &
Par contre, une fois le processus lancé, je ne sais pas s'il est
possible de bloquer le signal. Il faut certainement consulter l'aide de
ton shell en recherchant les commandes de gestion des Táches (commandes
jobs, fg, bg ... sous bash). Tu y trouveras peut etre ton bonheur.
Fanfan
François Cerbelle a écrit :Bulot gregory a écrit :Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le
process
tourne toujours (ps -aef ?)
Ca ne peut pas marcher car la fermeture de session va tuer le shell
qui va envoyer le signal HUP à tous ses fils. C'est pourquoi il existe
la commande "nohup" pour executer un process en indiquant qu'il ne
doit pas recevoir ce signal :
nohup commande &
Par contre, une fois le processus lancé, je ne sais pas s'il est
possible de bloquer le signal. Il faut certainement consulter l'aide
de ton shell en recherchant les commandes de gestion des Táches
(commandes jobs, fg, bg ... sous bash). Tu y trouveras peut etre ton
bonheur.
Fanfan
En faisant la recherche "bash bg nohup hup" dans Google, le premier
résultat est de WikiPedia et l'extrait donné par Google est prometteur.
La page WikiPedia donne les informations suivantes à tenter :
Existing jobs
Some shells (e.g. bash) provide a shell builtin that may be used to
prevent SIGHUP being sent or propagated to existing jobs, even if they
were not started with nohup. In bash, this can be obtained by using
disown -h job; using the same builtin without arguments removes the job
from the job table, which also implies that the job will not receive the
signal. Another relevant bash option is shopt huponexit, which
automatically sends the HUP signal to jobs when the shell is exiting
normally.
Fanfan
François Cerbelle a écrit :
Bulot gregory a écrit :
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le
process
tourne toujours (ps -aef ?)
Ca ne peut pas marcher car la fermeture de session va tuer le shell
qui va envoyer le signal HUP à tous ses fils. C'est pourquoi il existe
la commande "nohup" pour executer un process en indiquant qu'il ne
doit pas recevoir ce signal :
nohup commande &
Par contre, une fois le processus lancé, je ne sais pas s'il est
possible de bloquer le signal. Il faut certainement consulter l'aide
de ton shell en recherchant les commandes de gestion des Táches
(commandes jobs, fg, bg ... sous bash). Tu y trouveras peut etre ton
bonheur.
Fanfan
En faisant la recherche "bash bg nohup hup" dans Google, le premier
résultat est de WikiPedia et l'extrait donné par Google est prometteur.
La page WikiPedia donne les informations suivantes à tenter :
Existing jobs
Some shells (e.g. bash) provide a shell builtin that may be used to
prevent SIGHUP being sent or propagated to existing jobs, even if they
were not started with nohup. In bash, this can be obtained by using
disown -h job; using the same builtin without arguments removes the job
from the job table, which also implies that the job will not receive the
signal. Another relevant bash option is shopt huponexit, which
automatically sends the HUP signal to jobs when the shell is exiting
normally.
Fanfan
François Cerbelle a écrit :Bulot gregory a écrit :Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...
[désolé pour le mail privé coupé ...]
donc, j'ai pas tester, essayer sur un élément moins critique :
ctrl+z puis 'bg' (ºckground), après une déco, vérifier que le
process
tourne toujours (ps -aef ?)
Ca ne peut pas marcher car la fermeture de session va tuer le shell
qui va envoyer le signal HUP à tous ses fils. C'est pourquoi il existe
la commande "nohup" pour executer un process en indiquant qu'il ne
doit pas recevoir ce signal :
nohup commande &
Par contre, une fois le processus lancé, je ne sais pas s'il est
possible de bloquer le signal. Il faut certainement consulter l'aide
de ton shell en recherchant les commandes de gestion des Táches
(commandes jobs, fg, bg ... sous bash). Tu y trouveras peut etre ton
bonheur.
Fanfan
En faisant la recherche "bash bg nohup hup" dans Google, le premier
résultat est de WikiPedia et l'extrait donné par Google est prometteur.
La page WikiPedia donne les informations suivantes à tenter :
Existing jobs
Some shells (e.g. bash) provide a shell builtin that may be used to
prevent SIGHUP being sent or propagated to existing jobs, even if they
were not started with nohup. In bash, this can be obtained by using
disown -h job; using the same builtin without arguments removes the job
from the job table, which also implies that the job will not receive the
signal. Another relevant bash option is shopt huponexit, which
automatically sends the HUP signal to jobs when the shell is exiting
normally.
Fanfan
> J'ai pensé à la même chose mais j'ai testé (avec la commande top par
exemple) et ça ne marche pas. La déco tue le process.
> J'ai pensé à la même chose mais j'ai testé (avec la commande top par
exemple) et ça ne marche pas. La déco tue le process.
> J'ai pensé à la même chose mais j'ai testé (avec la commande top par
exemple) et ça ne marche pas. La déco tue le process.
Bonjour,
la commande screen est parfaite pour ce que tu veux faire :
http://kovyrin.net/2006/03/22/using-screen-window-manager-to-run-background-jobs/
Marc
Bonjour,
la commande screen est parfaite pour ce que tu veux faire :
http://kovyrin.net/2006/03/22/using-screen-window-manager-to-run-background-jobs/
Marc
Bonjour,
la commande screen est parfaite pour ce que tu veux faire :
http://kovyrin.net/2006/03/22/using-screen-window-manager-to-run-background-jobs/
Marc
mais une fois le prog lancé,
ça se complique.
mais une fois le prog lancé,
ça se complique.
mais une fois le prog lancé,
ça se complique.
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...le calcul tourne depuis pas mal de jours déjà j'aimerai donc
qu'il se finisse. Malheureusement une firme vient pour tester et peut
être changer les câbles ethernet...docn plus de net, donc plus de ssh
donc plus de calcul :'( Y a t il un moyen de "pousser" le calcul en
arrière plan et ainsi de le conserver même si la session ssh meurt ?
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...le calcul tourne depuis pas mal de jours déjà j'aimerai donc
qu'il se finisse. Malheureusement une firme vient pour tester et peut
être changer les câbles ethernet...docn plus de net, donc plus de ssh
donc plus de calcul :'( Y a t il un moyen de "pousser" le calcul en
arrière plan et ainsi de le conserver même si la session ssh meurt ?
Bonjour,
désolé pour ce HS. Tout est dans le titre :
j'ai lancé un calcul sur un ordinateur distant via SSH. J'ai fait la
bêtise de ne pas utiliser screen pensant que tout allait bien se
passer...le calcul tourne depuis pas mal de jours déjà j'aimerai donc
qu'il se finisse. Malheureusement une firme vient pour tester et peut
être changer les câbles ethernet...docn plus de net, donc plus de ssh
donc plus de calcul :'( Y a t il un moyen de "pousser" le calcul en
arrière plan et ainsi de le conserver même si la session ssh meurt ?