Ce dernier s'est soit relancé tout seul avant de se terminer (voir log
du processus pour voir pourquoi, si le code est « propre » -- ajouter un
verbose si nécessaire), soit il est mort et a été relancé (fréquent,
surtout si fils de init PID 1 : voir log /var/log/messages).
Un PID affecté ne change JAMAIS tant que son processus est présent
(actif ou non).
HTH
Alain Vaugham a écrit :
Le Friday 04 June 2010 12:00:07 François Cerbelle, vous avez écrit :
[...]
le noyau réutilise les PID morts (mais pas les zombies).
[...]
C'est donc tout a fait normal. Pour ton screen, tu devrait plutot noter
et utilise le nom de la session qui t'intéresse, il me semble que
"screen -ls" te les liste (vérifie dans le man).
Bonjour et merci beaucoup pour cette explication du pid tournant.
Cependant, dans mon cas, les PID n'étaient pas morts. Ils n'ont jamais non
plus été interrompus de mon fait. Au moins un a été réaffecté. C'est ce que
je mentionnais hier avant de constat du squat :
$ screen -ls
There are screens on:
31522.flux-emails-entrants (02.06.2010 10:19:47) (Detached)
24897.john-the-ripper (01.06.2010 11:17:01) (Detached)
Aujourd'hui, en suivant le man, lorsque je "resume" sur le nom de session ou
sur le PID c'est un autre job qui s'affiche. Voici :
$ screen -r flux-emails-entrants
$ screen -r 31522
m'affichent tous les deux la session que j'avais créée initialement sous le
nom de "john-the-ripper" et qui avait été affectée tout aussi initialement au
PID 24897.
Je constate donc qu'une réaffectatoin de PID s'est faite sur un PID non-mort
avec pour corollaire que le nom de session Screen a suivi le nouveau PID.
C'est un peu déroutant si on doit retrouver une session par un script car ce
dernier ne sera pas prévenu qu'il y a eu échange de PID/nom de session.
_________________________________
Linux mailing list
[email protected]
http://lists.parinux.org/mailman/listinfo/linux
