Processus.. adoption d'un processus par init

**Francois Trazzi** · 01/06/2004, 20h27

Bonjour,

Quand on ferme une fenetre de terminal, ca ferme généralement également les processus lancés depuis celle ci (également ceux en tache de fond) :
Cependant je crois que c'est possible de faire adopter des processus par le processus init (0)
Quelqu'un pourrait confirmer ce que je dis ?
et si c'est possible comment faire ?

Merci

**Smortex** · 01/06/2004, 23h34

Il faut regarder du cote de nohup...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
man nohup
nohup xeyes &
exit

**RuneSky** · 02/06/2004, 00h29

J'ai l'impression qu'avec MDK 10, le simple fait de rajouter & à la fin détache le programme de la console parent... par exemple si je lance konqueror &, et que je ferme ensuite la console, konqueror reste...

**Francois Trazzi** · 02/06/2004, 07h12

Merci Smortex, je vais essayer ca..

OracleConcept : Apparement ca dépend plutot des fenêtres de terminal.. ou des shells..

**Pongten** · 02/06/2004, 09h09

En fait, le comportement par défaut d'un processus "fils" lorsque son processus "père" se termine, est d'être adopté par le processus "init", mais pour les processus lancés depuis des sessions graphiques, ça dépend du gestionnaire et des choix qu'ils ont fait...

Ce qu'il faudrait vérifier, c'est que quand on ferme une fenêtre de terminal, il n'envoie pas un "kill -9" à tous les processus qu'elle contient...

**MarcG** · 02/06/2004, 10h36

FAUX

le comportement par defaut normal et lors de la mort du père le fils est tué par le system (signal SIGTERM et SIGCHILD)

la commande "nohup" "rattache" le process a init et permet donc la mort du père d'origine sans tué le(s) fils.

Dans le cas de KDE c'est une questions d'implementation de certain programme tel konqueror : tout comme l'exploreur sous Windows, konqueror fait parti integrante de KDE (son moteur pour le moins) et donc ce n'est pas un "vrai" processus mais une thread du prog principale.

**Smortex** · 02/06/2004, 11h54

Tout est explique dans la doc de nohup :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
     The nohup utility invokes utility with its arguments and at this time
     sets the signal SIGHUP to be ignored.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
     Some shells may provide a builtin nohup command which is similar or iden-
     tical to this utility.  Consult the builtin(1) manual page.

Et comme le dit MarcG, certains processus sont en fait des Thread, et d'autres se forkent d'eux meme, tel que gvim, si vous le lancer sans rien deriere (pas de &), vous aurez qund meme acces a votre terminal et pourrez le fermer sans tuer gvim...

**Pongten** · 02/06/2004, 13h13

Envoyé par MarcG

FAUX

le comportement par defaut normal et lors de la mort du père le fils est tué par le system (signal SIGTERM et SIGCHILD)

Pas d'accord... rédige un programme qui fait un fork(), puis qui dans le fils fait un traitement assez long (plus long que la durée de vie du père).
Si il n'y a pas de wait dans le père, il va terminer son exécution et mourrir. Le fils quand à lui sera rataché au processus init et terminera ce qu'il a à faire !

**jmv** · 03/06/2004, 08h50

Envoyé par MarcG

FAUX
le comportement par defaut normal et lors de la mort du père le fils est tué par le system (signal SIGTERM et SIGCHILD)

C'est Pongten qui a raison, par defaut un processus fils continue même si son père est terminé. Mais pour les shell (texte ou graphique) c'est différents, lorsqu'un shell se termine, il envoie le signal SIGHUP à tous les processus de son groupe (lancé depuis le même shell). D'où l'utilité de la commande nohup dans certains cas

**Francois Trazzi** · 03/06/2004, 20h44

Envoyé par Smortex

Il faut regarder du cote de nohup...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
man nohup
nohup xeyes &
exit

euh.. tu es sur que c'est "nohup" la commande :
man nohup me donne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
NOHUP(1)                         User Commands                        NOHUP(1)
 
NAME
       nohup - run a command immune to hangups, with output to a non-tty
 
SYNOPSIS
       nohup COMMAND [ARG]...
       nohup OPTION
 
DESCRIPTION
       Run COMMAND, ignoring hangup signals.
 
       --help display this help and exit
 
       --version
              output version information and exit

et après AUTHOR, ...
Il n'y a aucune options ? ... ?

Si par exmeple j'ai un processus déja existant.. et je veux que celui ci soit adopté par init, c'ets pas possible ?

**Smortex** · 03/06/2004, 21h06

Ta doc me semble light.... Sous FreeBSD, j'en ai un peu plus :

NOHUP(1) FreeBSD General Commands Manual NOHUP(1)

NAME
nohup -- invoke a utility immune to hangups

SYNOPSIS
nohup [--] utility [arguments]

DESCRIPTION
The nohup utility invokes utility with its arguments and at this time
sets the signal SIGHUP to be ignored. If the standard output is a termi-
nal, the standard output is appended to the file nohup.out in the current
directory. If standard error is a terminal, it is directed to the same
place as the standard output.

Some shells may provide a builtin nohup command which is similar or iden-
tical to this utility. Consult the builtin(1) manual page.

ENVIRONMENT
The following variables are utilized by nohup:

HOME If the output file nohup.out cannot be created in the current
directory, the nohup utility uses the directory named by HOME to
create the file.

PATH Used to locate the requested utility if the name contains no `/'
characters.

DIAGNOSTICS
The nohup utility exits with one of the following values:

126 The utility was found, but could not be invoked.

127 The utility could not be found or an error occurred in nohup.

Otherwise, the exit status of nohup will be that of utility.

SEE ALSO
builtin(1), csh(1), signal(3)

STANDARDS
The nohup utility is expected to be IEEE Std 1003.2 (``POSIX.2'') compat-
ible.

BUGS
Two or more instances of nohup can append to the same file, which makes
for a confusing output.

FreeBSD 5.2.1 July 19, 2001 FreeBSD 5.2.1

Bref, ca sert a lancer un programme en ne lui fesant pas tenir compte d'un signal SIGHUP... Ca ne peux pas le dire a un programme qui tourne deja... Je ne connais pas d'utilitaires permettant de faire ce que tu desire...

**Francois Trazzi** · 03/06/2004, 23h37

Merci smortex et

aux autres personnes également

**bodtx** · 16/01/2005, 22h54

Oué nohup est bien pratique.
Bon ceci dit j'ai un problème j'ai récupéré sirc qui un client irc en ligne de commande.
Je voulais le lancer puis quitter la session sans deconnecter le client irc.
Je fais donc un nohup sh sirc .....
ca se passe bien mais quand je quitte la session paf, je suis déconnecté de irc et le processus s'arrete... zarb.
C ecrit en perl, je sais pas trop comment les processus sont gérés.

Merci

**ALT** · 17/01/2005, 11h06

Là j'ai pas compris : ça sert à quoi de conserver un client IRC hors connexion ?

En tout état de cause, si ça le déconnecte, c'est peut-être parce qu'un autre processus indispensable est arrêté automatiquement à la déconnexion.