rendre un processus insensible à l'interruption du parent
7 réponses
Manuel Pégourié-Gonnard
Bonjour,
Imaginons que depuis un shell je lance un programme (mettons vim),
depuis lequel j'en lance un autre (mettons xpdf) en arrière-plan (& en
fin de ligne de commande). Depuis vim, je fais un petit Ctrl-Z pour
aller bidouiller dans mon shell de départ, et revenir à vim avec tous
mes buffers et mes fenêtres ouvertes par un simple 'fg'.
Mon souci est que lorsque vim est suspendu par Ctrl-Z, xpdf l'est
aussi, alors que je préférerais qu'il ne le soit pas. J'imagine que la
solution tient à la façon de lancer xpdf depuis vim. J'ai essayé de le
faire déposséder par le shell qui sert à le lancer (un zsh) en faisant
nohup xpdf file.pdf &|
mais sans succès. Toute piste est la bienvenue.
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
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
Nicolas George
Manuel Pégourié-Gonnard wrote in message :
Mon souci est que lorsque vim est suspendu par Ctrl-Z, xpdf l'est aussi, alors que je préférerais qu'il ne le soit pas. J'imagine que la solution tient à la façon de lancer xpdf depuis vim. J'ai essayé de le faire déposséder par le shell qui sert à le lancer (un zsh) en faisant
nohup xpdf file.pdf &|
nohup ne sert essentiellement à rien, c'est une commande à oublier.
Idéalement, il faudrait créer un nouveau groupe de process. À défaut, dans le cas présent, créer une nouvelle session convient parfaitement, ce qui peut se faire avec l'appel système setsid. Sur les bons systèmes, il y a une commande correspondante, setsid par exemple.
Manuel Pégourié-Gonnard wrote in message
<20090722134224.11317.8786.XPN@roth.elzevir.fr>:
Mon souci est que lorsque vim est suspendu par Ctrl-Z, xpdf l'est
aussi, alors que je préférerais qu'il ne le soit pas. J'imagine que la
solution tient à la façon de lancer xpdf depuis vim. J'ai essayé de le
faire déposséder par le shell qui sert à le lancer (un zsh) en faisant
nohup xpdf file.pdf &|
nohup ne sert essentiellement à rien, c'est une commande à oublier.
Idéalement, il faudrait créer un nouveau groupe de process. À défaut, dans
le cas présent, créer une nouvelle session convient parfaitement, ce qui
peut se faire avec l'appel système setsid. Sur les bons systèmes, il y a une
commande correspondante, setsid par exemple.
Mon souci est que lorsque vim est suspendu par Ctrl-Z, xpdf l'est aussi, alors que je préférerais qu'il ne le soit pas. J'imagine que la solution tient à la façon de lancer xpdf depuis vim. J'ai essayé de le faire déposséder par le shell qui sert à le lancer (un zsh) en faisant
nohup xpdf file.pdf &|
nohup ne sert essentiellement à rien, c'est une commande à oublier.
Idéalement, il faudrait créer un nouveau groupe de process. À défaut, dans le cas présent, créer une nouvelle session convient parfaitement, ce qui peut se faire avec l'appel système setsid. Sur les bons systèmes, il y a une commande correspondante, setsid par exemple.
Manuel Pégourié-Gonnard
Nicolas George scripsit:
Manuel Pégourié-Gonnard wrote in message :
Mon souci est que lorsque vim est suspendu par Ctrl-Z, xpdf l'est aussi, alors que je préférerais qu'il ne le soit pas. J'imagine que la solution tient à la façon de lancer xpdf depuis vim. J'ai essayé de le faire déposséder par le shell qui sert à le lancer (un zsh) en faisant
nohup xpdf file.pdf &|
nohup ne sert essentiellement à rien, c'est une commande à oublier.
Ok. Il me semble que j'en avais eu besoin à un moment pour pouvoir fermer ma session shell (zsh) sans pour autant tuer les processus lancés depuis ce shell.
Enfin dans ce cas, je dois avouer l'avoir mis là un peu au hasard.
Idéalement, il faudrait créer un nouveau groupe de process. À défaut, dans le cas présent, créer une nouvelle session convient parfaitement, ce qui peut se faire avec l'appel système setsid. Sur les bons systèmes, il y a une commande correspondante, setsid par exemple.
En effet, j'ai un /usr/bin/setsid dont l'utilisation résoud le problème. Merci !
Pour comprendre un peu mieux la gestion des processus sous Unix (par exemple les notions de session et de groupe de processus), que puis-je lire (si possible librement disponible) ?
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Nicolas George scripsit:
Manuel Pégourié-Gonnard wrote in message
<20090722134224.11317.8786.XPN@roth.elzevir.fr>:
Mon souci est que lorsque vim est suspendu par Ctrl-Z, xpdf l'est
aussi, alors que je préférerais qu'il ne le soit pas. J'imagine que la
solution tient à la façon de lancer xpdf depuis vim. J'ai essayé de le
faire déposséder par le shell qui sert à le lancer (un zsh) en faisant
nohup xpdf file.pdf &|
nohup ne sert essentiellement à rien, c'est une commande à oublier.
Ok. Il me semble que j'en avais eu besoin à un moment pour pouvoir
fermer ma session shell (zsh) sans pour autant tuer les processus lancés
depuis ce shell.
Enfin dans ce cas, je dois avouer l'avoir mis là un peu au hasard.
Idéalement, il faudrait créer un nouveau groupe de process. À défaut, dans
le cas présent, créer une nouvelle session convient parfaitement, ce qui
peut se faire avec l'appel système setsid. Sur les bons systèmes, il y a une
commande correspondante, setsid par exemple.
En effet, j'ai un /usr/bin/setsid dont l'utilisation résoud le problème.
Merci !
Pour comprendre un peu mieux la gestion des processus sous Unix (par
exemple les notions de session et de groupe de processus), que
puis-je lire (si possible librement disponible) ?
--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Mon souci est que lorsque vim est suspendu par Ctrl-Z, xpdf l'est aussi, alors que je préférerais qu'il ne le soit pas. J'imagine que la solution tient à la façon de lancer xpdf depuis vim. J'ai essayé de le faire déposséder par le shell qui sert à le lancer (un zsh) en faisant
nohup xpdf file.pdf &|
nohup ne sert essentiellement à rien, c'est une commande à oublier.
Ok. Il me semble que j'en avais eu besoin à un moment pour pouvoir fermer ma session shell (zsh) sans pour autant tuer les processus lancés depuis ce shell.
Enfin dans ce cas, je dois avouer l'avoir mis là un peu au hasard.
Idéalement, il faudrait créer un nouveau groupe de process. À défaut, dans le cas présent, créer une nouvelle session convient parfaitement, ce qui peut se faire avec l'appel système setsid. Sur les bons systèmes, il y a une commande correspondante, setsid par exemple.
En effet, j'ai un /usr/bin/setsid dont l'utilisation résoud le problème. Merci !
Pour comprendre un peu mieux la gestion des processus sous Unix (par exemple les notions de session et de groupe de processus), que puis-je lire (si possible librement disponible) ?
-- Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Stephane CHAZELAS
2009-07-22, 17:57(+02), Manuel Pégourié-Gonnard: [...]
Pour comprendre un peu mieux la gestion des processus sous Unix (par exemple les notions de session et de groupe de processus), que puis-je lire (si possible librement disponible) ?
info libc 'job control'
sur un systeme GNU.
-- Stéphane
2009-07-22, 17:57(+02), Manuel Pégourié-Gonnard:
[...]
Pour comprendre un peu mieux la gestion des processus sous Unix (par
exemple les notions de session et de groupe de processus), que
puis-je lire (si possible librement disponible) ?
2009-07-22, 17:57(+02), Manuel Pégourié-Gonnard: [...]
Pour comprendre un peu mieux la gestion des processus sous Unix (par exemple les notions de session et de groupe de processus), que puis-je lire (si possible librement disponible) ?
info libc 'job control'
sur un systeme GNU.
-- Stéphane
NicolasAlex.Michel.remove
Manuel Pégourié-Gonnard <mpg+ wrote:
Ok. Il me semble que j'en avais eu besoin à un moment pour pouvoir fermer ma session shell (zsh) sans pour autant tuer les processus lancés depuis ce shell.
Dans un cas comme ça, perso j'utilise screen.
Avec l'avantage de pouvoir reprendre la main le landemain pour consulter les éventuels messages d'erreur.
-- Nicolas Michel
Manuel Pégourié-Gonnard <mpg+news@elzevir.fr> wrote:
Ok. Il me semble que j'en avais eu besoin à un moment pour pouvoir
fermer ma session shell (zsh) sans pour autant tuer les processus lancés
depuis ce shell.
Dans un cas comme ça, perso j'utilise screen.
Avec l'avantage de pouvoir reprendre la main le landemain pour consulter
les éventuels messages d'erreur.
Ok. Il me semble que j'en avais eu besoin à un moment pour pouvoir fermer ma session shell (zsh) sans pour autant tuer les processus lancés depuis ce shell.
Dans un cas comme ça, perso j'utilise screen.
Avec l'avantage de pouvoir reprendre la main le landemain pour consulter les éventuels messages d'erreur.
-- Nicolas Michel
Lucas Levrel
Le 22 juillet 2009, Stephane CHAZELAS a écrit :
info libc 'job control'
sur un systeme GNU.
Qu'on peut trouver en PDF (entre autres) là : http://www.gnu.org/software/libc/manual/
-- LL
Le 22 juillet 2009, Stephane CHAZELAS a écrit :
info libc 'job control'
sur un systeme GNU.
Qu'on peut trouver en PDF (entre autres) là :
http://www.gnu.org/software/libc/manual/
Qu'on peut trouver en PDF (entre autres) là : http://www.gnu.org/software/libc/manual/
-- LL
yamo'
Salut,
Nicolas Michel a tapoté, le 23/07/2009 08:49 :
Dans un cas comme ça, perso j'utilise screen.
J'utilise beaucoup screen mais j'ai découvert récemment nohup sur un serveur CentOS 4 qui tenait à tout prix à associer le processus tomcat à ma session ouverte avec Putty et screen dans ce cas là ne voulait pas fonctionner ou alors je n'avais pas la bonne option et un simple & était inefficace.
Il y a peut-être un moyen simple pour détacher d'une session/processus père (je ne sais pas si le terme est approprié) un processus existant?
-- Stéphane http://pasdenom.info/fortune/
Salut,
Nicolas Michel a tapoté, le 23/07/2009 08:49 :
Dans un cas comme ça, perso j'utilise screen.
J'utilise beaucoup screen mais j'ai découvert récemment nohup sur un
serveur CentOS 4 qui tenait à tout prix à associer le processus tomcat à
ma session ouverte avec Putty et screen dans ce cas là ne voulait pas
fonctionner ou alors je n'avais pas la bonne option et un simple & était
inefficace.
Il y a peut-être un moyen simple pour détacher d'une session/processus
père (je ne sais pas si le terme est approprié) un processus existant?
J'utilise beaucoup screen mais j'ai découvert récemment nohup sur un serveur CentOS 4 qui tenait à tout prix à associer le processus tomcat à ma session ouverte avec Putty et screen dans ce cas là ne voulait pas fonctionner ou alors je n'avais pas la bonne option et un simple & était inefficace.
Il y a peut-être un moyen simple pour détacher d'une session/processus père (je ne sais pas si le terme est approprié) un processus existant?
-- Stéphane http://pasdenom.info/fortune/
Nicolas George
yamo' wrote in message <4a6acc68$:
J'utilise beaucoup screen mais j'ai découvert récemment nohup sur un serveur CentOS 4 qui tenait à tout prix à associer le processus tomcat à ma session ouverte avec Putty et screen dans ce cas là ne voulait pas fonctionner ou alors je n'avais pas la bonne option et un simple & était inefficace.
Il y a peut-être un moyen simple pour détacher d'une session/processus père (je ne sais pas si le terme est approprié) un processus existant?
nuhup ne détache pas le processus. La bonne commande pour détacher, c'est setsid. Il faut également penser à rediriger les entrées-sorties, évidemment.
yamo' wrote in message <4a6acc68$1@groumpf.org>:
J'utilise beaucoup screen mais j'ai découvert récemment nohup sur un
serveur CentOS 4 qui tenait à tout prix à associer le processus tomcat à
ma session ouverte avec Putty et screen dans ce cas là ne voulait pas
fonctionner ou alors je n'avais pas la bonne option et un simple & était
inefficace.
Il y a peut-être un moyen simple pour détacher d'une session/processus
père (je ne sais pas si le terme est approprié) un processus existant?
nuhup ne détache pas le processus. La bonne commande pour détacher, c'est
setsid. Il faut également penser à rediriger les entrées-sorties,
évidemment.
J'utilise beaucoup screen mais j'ai découvert récemment nohup sur un serveur CentOS 4 qui tenait à tout prix à associer le processus tomcat à ma session ouverte avec Putty et screen dans ce cas là ne voulait pas fonctionner ou alors je n'avais pas la bonne option et un simple & était inefficace.
Il y a peut-être un moyen simple pour détacher d'une session/processus père (je ne sais pas si le terme est approprié) un processus existant?
nuhup ne détache pas le processus. La bonne commande pour détacher, c'est setsid. Il faut également penser à rediriger les entrées-sorties, évidemment.
