USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 5048 4.7 0.0 0 0 ? Ds 14:24 5:22 [Xorg]
1. Le processus prend du temps machine (4.7% cpu...)
2. Je n'arrive pas à le tuer (il survit à un kill -9)
3. Pas moyen d'accéder à la console sur la machine : l'écran est noir et le
clavier est inopérant (j'y accède uniquement par ssh)
Est-ce qu'il y a un moyen de tuer ce process quand même (et regagner l'accès
à la console) ?
NB je présume (mais je n'ai pas encore vérifié que les magic keys
fonctionnent) mais reste deux questions :
- Que puis-je faire avant d'en ven ir aux magic keys
- Qui monopolise le clavier (est-ce bien ce Xorg) ?
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
J'ai trop coupé : probablement pas moyen de le tuer.
il a probablement mis le la carte vidéo en vrac,
Il un mot dans cette phrase.
Le « le » est en trop.
et peut-être une partie du bus système.
C'est à dire ? Tu supposes une panne matérielle, impliquant le proc graphique ?
Non, probablement pas une panne matérielle. Mais un problème logiciel qui place certains composants dans un état qui n'est pas prévu par le reste du système.
Yves Lambert wrote in message <0ur9r6xqgo.ln2@phoenix.bidart.net>:
Probablement pas,
J'ai trop coupé : probablement pas moyen de le tuer.
il a probablement mis le
la carte vidéo en vrac,
Il un mot dans cette phrase.
Le « le » est en trop.
et peut-être une partie du bus système.
C'est à dire ?
Tu supposes une panne matérielle, impliquant le proc graphique ?
Non, probablement pas une panne matérielle. Mais un problème logiciel qui
place certains composants dans un état qui n'est pas prévu par le reste du
système.
J'ai trop coupé : probablement pas moyen de le tuer.
il a probablement mis le la carte vidéo en vrac,
Il un mot dans cette phrase.
Le « le » est en trop.
et peut-être une partie du bus système.
C'est à dire ? Tu supposes une panne matérielle, impliquant le proc graphique ?
Non, probablement pas une panne matérielle. Mais un problème logiciel qui place certains composants dans un état qui n'est pas prévu par le reste du système.
Yves Lambert
Nicolas George wrote:
Non, probablement pas une panne matérielle. Mais un problème logiciel qui place certains composants dans un état qui n'est pas prévu par le reste du système.
Bon, en reprenant tes conclusions est celles de Guigui, c'est un probable bug du driver (ATI "radeon"). - J'ai réusi à le tuer (syst+K) et depuis pas de souci (j'ai même redémarré le démon gdm pou voir) Il me semble avoir vérifié si le process avait des fils (j'ai dû faire "ps -Al|grep pid" pour trouver le père (init) et s'il avait eu des fils je m'en serai aperçu) Je vais essayer quand j'aurais le temps de reproduire les conditions initiales (après un reboot) - je vous tiendrai au courant.
Reste un mystère : comment se fait il que ce process supposé dormir prenait du CPU ?
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
Nicolas George wrote:
Non, probablement pas une panne matérielle. Mais un problème logiciel qui
place certains composants dans un état qui n'est pas prévu par le reste du
système.
Bon, en reprenant tes conclusions est celles de Guigui, c'est un probable
bug du driver (ATI "radeon").
- J'ai réusi à le tuer (syst+K) et depuis pas de souci (j'ai même redémarré
le démon gdm pou voir)
Il me semble avoir vérifié si le process avait des fils
(j'ai dû faire "ps -Al|grep pid" pour trouver le père (init) et s'il avait
eu des fils je m'en serai aperçu)
Je vais essayer quand j'aurais le temps de reproduire les conditions
initiales (après un reboot) - je vous tiendrai au courant.
Reste un mystère : comment se fait il que ce process supposé dormir prenait
du CPU ?
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
Non, probablement pas une panne matérielle. Mais un problème logiciel qui place certains composants dans un état qui n'est pas prévu par le reste du système.
Bon, en reprenant tes conclusions est celles de Guigui, c'est un probable bug du driver (ATI "radeon"). - J'ai réusi à le tuer (syst+K) et depuis pas de souci (j'ai même redémarré le démon gdm pou voir) Il me semble avoir vérifié si le process avait des fils (j'ai dû faire "ps -Al|grep pid" pour trouver le père (init) et s'il avait eu des fils je m'en serai aperçu) Je vais essayer quand j'aurais le temps de reproduire les conditions initiales (après un reboot) - je vous tiendrai au courant.
Reste un mystère : comment se fait il que ce process supposé dormir prenait du CPU ?
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
Yves Lambert
Yves Lambert wrote:
Reste deux questions : - Que puis-je faire avant d'en venir aux magic keys - Qui monopolise le clavier (est-ce bien ce Xorg) ?
Bon ça a recommencé, mais ce coup là l'économiseur d'écran était lancé (depuis moins de 10min sinon avec mon réglage l'écran aurait été en veille mais depuis un moment sans doute. Je l'ai laissé mariner dans son jus plusieurs heures, et comme rien n'avait bougé (l'écran affichait exactement la même chose que plusieurs heures auparavant et le klavier faisait le mort, accès ssh tout pareil, je n'ai pas suivi la même procédure parce que je ne voulais pas relancer gdm - il y avait la session d'un autre luser qui tournait
alt+sys+k a tué les deux serveurs X (logiquement ça n'aurait dû tuer que celui du terminal courant, non ?
Là le serveur X était dans l'état Ss+ d'après le man ps S Interruptible sleep (waiting for an event to complete) s is a session leader
+ is in the foreground process group J'ai pas regardé s'il prenait du temps CPU quand même, ce sera pour le prochain tour :)
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
Yves Lambert wrote:
Reste deux questions :
- Que puis-je faire avant d'en venir aux magic keys
- Qui monopolise le clavier (est-ce bien ce Xorg) ?
Bon ça a recommencé, mais ce coup là l'économiseur d'écran était lancé
(depuis moins de 10min sinon avec mon réglage l'écran aurait été en veille
mais depuis un moment sans doute. Je l'ai laissé mariner dans son jus
plusieurs heures, et comme rien n'avait bougé (l'écran affichait exactement
la même chose que plusieurs heures auparavant et le klavier faisait le mort,
accès ssh tout pareil, je n'ai pas suivi la même procédure parce que je ne
voulais pas relancer gdm - il y avait la session d'un autre luser qui tournait
alt+sys+k a tué les deux serveurs X (logiquement ça
n'aurait dû tuer que celui du terminal courant, non ?
Là le serveur X était dans l'état Ss+ d'après le man ps
S Interruptible sleep (waiting for an event to complete)
s is a session leader
+ is in the foreground process group
J'ai pas regardé s'il prenait du temps CPU quand même, ce sera pour le
prochain tour :)
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
Reste deux questions : - Que puis-je faire avant d'en venir aux magic keys - Qui monopolise le clavier (est-ce bien ce Xorg) ?
Bon ça a recommencé, mais ce coup là l'économiseur d'écran était lancé (depuis moins de 10min sinon avec mon réglage l'écran aurait été en veille mais depuis un moment sans doute. Je l'ai laissé mariner dans son jus plusieurs heures, et comme rien n'avait bougé (l'écran affichait exactement la même chose que plusieurs heures auparavant et le klavier faisait le mort, accès ssh tout pareil, je n'ai pas suivi la même procédure parce que je ne voulais pas relancer gdm - il y avait la session d'un autre luser qui tournait
alt+sys+k a tué les deux serveurs X (logiquement ça n'aurait dû tuer que celui du terminal courant, non ?
Là le serveur X était dans l'état Ss+ d'après le man ps S Interruptible sleep (waiting for an event to complete) s is a session leader
+ is in the foreground process group J'ai pas regardé s'il prenait du temps CPU quand même, ce sera pour le prochain tour :)
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
sebas22
Le Sat, 24 Oct 2009 01:53:44 +0200, Yves Lambert a ecrit :
1. Le processus prend du temps machine (4.7% cpu...) 2. Je n'arrive pas à le tuer (il survit à un kill -9)
Ça m'interesse aussi de savoir comment on peut tuer un processus non vital qui survit à un kill -9
Ça m'est encore arrivé ce soir avec wlassistant et claws mail,
alt+sys+k *avant* de redémarrer X aurait peut-être marché ;)
Merci pour ta réponse, j'arriver seulement maintenant, après la bataille, j'étais en vacances.
OK pour alt-sys-K, mais il n'y des processus qui tournent que je ne voudrais pas tuer, je voudrais juste me débarasser de ceux qui accaparent le CPU et laisser tourner les autres. Je ne comprends pas d'ailleurs pourquoi le SIGKILL ne mets pas radicalement fin au processus et que celui-ci y survit.
Ciao Sebas
Le Sat, 24 Oct 2009 01:53:44 +0200, Yves Lambert a ecrit :
1. Le processus prend du temps machine (4.7% cpu...) 2. Je n'arrive
pas à le tuer (il survit à un kill -9)
Ça m'interesse aussi de savoir comment on peut tuer un processus non
vital qui survit à un kill -9
Ça m'est encore arrivé ce soir avec wlassistant et claws mail,
alt+sys+k *avant* de redémarrer X aurait peut-être marché ;)
Merci pour ta réponse, j'arriver seulement maintenant, après la bataille,
j'étais en vacances.
OK pour alt-sys-K, mais il n'y des processus qui tournent que je ne
voudrais pas tuer, je voudrais juste me débarasser de ceux qui accaparent
le CPU et laisser tourner les autres. Je ne comprends pas d'ailleurs
pourquoi le SIGKILL ne mets pas radicalement fin au processus et que
celui-ci y survit.
Le Sat, 24 Oct 2009 01:53:44 +0200, Yves Lambert a ecrit :
1. Le processus prend du temps machine (4.7% cpu...) 2. Je n'arrive pas à le tuer (il survit à un kill -9)
Ça m'interesse aussi de savoir comment on peut tuer un processus non vital qui survit à un kill -9
Ça m'est encore arrivé ce soir avec wlassistant et claws mail,
alt+sys+k *avant* de redémarrer X aurait peut-être marché ;)
Merci pour ta réponse, j'arriver seulement maintenant, après la bataille, j'étais en vacances.
OK pour alt-sys-K, mais il n'y des processus qui tournent que je ne voudrais pas tuer, je voudrais juste me débarasser de ceux qui accaparent le CPU et laisser tourner les autres. Je ne comprends pas d'ailleurs pourquoi le SIGKILL ne mets pas radicalement fin au processus et que celui-ci y survit.
