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
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) ?
Dans quel état est le processus parent (si il y en a un) ? Normalement c'est le commutateur f de ps pour afficher la filiation.
Yves Lambert a écrit :
Bonjour, j'ai un petit souci :
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) ?
Dans quel état est le processus parent (si il y en a un) ?
Normalement c'est le commutateur f de ps pour afficher la filiation.
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) ?
Dans quel état est le processus parent (si il y en a un) ? Normalement c'est le commutateur f de ps pour afficher la filiation.
GuiGui
GuiGui a écrit :
Yves Lambert a écrit :
Bonjour, j'ai un petit souci :
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) ?
Dans quel état est le processus parent (si il y en a un) ? Normalement c'est le commutateur f de ps pour afficher la filiation.
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil qui consomme du CPU ?
GuiGui a écrit :
Yves Lambert a écrit :
Bonjour, j'ai un petit souci :
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) ?
Dans quel état est le processus parent (si il y en a un) ?
Normalement c'est le commutateur f de ps pour afficher la filiation.
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil
qui consomme du CPU ?
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) ?
Dans quel état est le processus parent (si il y en a un) ? Normalement c'est le commutateur f de ps pour afficher la filiation.
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil qui consomme du CPU ?
Nicolas George
Yves Lambert wrote in message :
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)
Probablement pas, ton serveur X11 est bien planté, il a probablement mis le la carte vidéo en vrac, et peut-être une partie du bus système.
Yves Lambert wrote in message <t8s8r6xar9.ln2@phoenix.bidart.net>:
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)
Probablement pas, ton serveur X11 est bien planté, il a probablement mis le
la carte vidéo en vrac, et peut-être une partie du bus système.
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)
Probablement pas, ton serveur X11 est bien planté, il a probablement mis le la carte vidéo en vrac, et peut-être une partie du bus système.
YBM
Yves Lambert a écrit :
Bonjour, j'ai un petit souci :
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 venir aux magic keys
su -c halt ou sudo halt
Yves Lambert a écrit :
Bonjour, j'ai un petit souci :
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 venir aux magic keys
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 venir aux magic keys
su -c halt ou sudo halt
sebas22
Bonjour,
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, pas moyen de les tuer même pas avec redemarage de X ni avec init 3, comme ils bouffaient du CPU et que le ventilo de mon laptop tournait non-stop, j'ai dû rebooter, la honte, heureusement qu'il n'y avait pas de windowsien pour voir ça ;-)
Ciao
Bonjour,
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, pas moyen
de les tuer même pas avec redemarage de X ni avec init 3, comme ils
bouffaient du CPU et que le ventilo de mon laptop tournait non-stop, j'ai
dû rebooter, la honte, heureusement qu'il n'y avait pas de windowsien
pour voir ça ;-)
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, pas moyen de les tuer même pas avec redemarage de X ni avec init 3, comme ils bouffaient du CPU et que le ventilo de mon laptop tournait non-stop, j'ai dû rebooter, la honte, heureusement qu'il n'y avait pas de windowsien pour voir ça ;-)
Ciao
Yves Lambert
GuiGui wrote:
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil qui consomme du CPU ?
Oui.
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
GuiGui wrote:
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil
qui consomme du CPU ?
Oui.
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil qui consomme du CPU ?
Oui.
-- 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
Nicolas George wrote:
Yves Lambert wrote in message :
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)
Probablement pas,
Probablement pas quoi ?
ton serveur X11 est bien planté,
Oui
il a probablement mis le la carte vidéo en vrac,
Il un mot dans cette phrase.
et peut-être une partie du bus système.
C'est à dire ? Tu supposes une panne matérielle, impliquant le proc graphique ?
Bon je vais donner des précisions :
je suis sur une session X banale, avec xscreensaver aux aguêts. Comme j'ai mis une tempo courte, l'économiseur d'écran s'enclenche (ilm tourne tout à fait normalement (vu en accès distant dans la table des process.) après le fade, problème la console est planté. Je me connecte en ssh sur la machine, je tue xscreensaver et son fils, je reviens sur la console, idem. Je tue la session X, le PC beepe, je reviens dessus toujours planté. J'ai gdm : sudo gdm stop pareil. Des fois quand X est planté, ouvrir un nouveau serveur libère la console : sudo X :1 Xorg après interruption se plaint : Fatal server error: xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
ça faisait un petit moment qu'il était dans cet état là.
je reviens à ma table de process : je vois qu'il y a un Xorg qui traîne. Je cherche à le tuer pas moyen. Je reboote (sudo reboot depuis la connexion ssh, je me relogue (gdm) ça recommence (console bloquée idem, rien à l'écran, toujours bloquée après avoir tué le démon et l'économiseur d'écran ( qui n'es ni un process qui accède à internet style webcollage ni un qui bouffe du CPU ou de la mémoire) je termine la sesssion, j'arrête gdm (invoke-rc.d gdm stop) plus de process gdm mais la console bloquée. les magic keys fonctionnent alt+sys+k suffit à libérer la console je redémarre gdm et depuis plus de souci (xscreensaver lance normalement l'économiseur d'écran, la console ne se bloque pas...
-- 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:
Yves Lambert wrote in message <t8s8r6xar9.ln2@phoenix.bidart.net>:
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)
Probablement pas,
Probablement pas quoi ?
ton serveur X11 est bien planté,
Oui
il a probablement mis le
la carte vidéo en vrac,
Il un mot dans cette phrase.
et peut-être une partie du bus système.
C'est à dire ?
Tu supposes une panne matérielle, impliquant le proc graphique ?
Bon je vais donner des précisions :
je suis sur une session X banale, avec xscreensaver aux aguêts.
Comme j'ai mis une tempo courte, l'économiseur d'écran s'enclenche (ilm
tourne tout à fait normalement (vu en accès distant dans la table des
process.) après le fade, problème la console est planté.
Je me connecte en ssh sur la machine, je tue xscreensaver et son fils, je
reviens sur la console, idem. Je tue la session X, le PC beepe, je reviens
dessus toujours planté. J'ai gdm :
sudo gdm stop
pareil.
Des fois quand X est planté, ouvrir un nouveau serveur libère la console :
sudo X :1
Xorg après interruption se plaint :
Fatal server error:
xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
ça faisait un petit moment qu'il était dans cet état là.
je reviens à ma table de process : je vois qu'il y a un Xorg qui traîne. Je
cherche à le tuer pas moyen.
Je reboote (sudo reboot depuis la connexion ssh, je me relogue (gdm) ça
recommence (console bloquée idem, rien à l'écran, toujours bloquée après
avoir tué le démon et l'économiseur d'écran
( qui n'es ni un process qui accède à internet style webcollage ni un qui
bouffe du CPU ou de la mémoire)
je termine la sesssion, j'arrête gdm (invoke-rc.d gdm stop) plus de process
gdm mais la console bloquée.
les magic keys fonctionnent alt+sys+k suffit à libérer la console je
redémarre gdm et depuis plus de souci (xscreensaver lance normalement
l'économiseur d'écran, la console ne se bloque pas...
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
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)
Probablement pas,
Probablement pas quoi ?
ton serveur X11 est bien planté,
Oui
il a probablement mis le la carte vidéo en vrac,
Il un mot dans cette phrase.
et peut-être une partie du bus système.
C'est à dire ? Tu supposes une panne matérielle, impliquant le proc graphique ?
Bon je vais donner des précisions :
je suis sur une session X banale, avec xscreensaver aux aguêts. Comme j'ai mis une tempo courte, l'économiseur d'écran s'enclenche (ilm tourne tout à fait normalement (vu en accès distant dans la table des process.) après le fade, problème la console est planté. Je me connecte en ssh sur la machine, je tue xscreensaver et son fils, je reviens sur la console, idem. Je tue la session X, le PC beepe, je reviens dessus toujours planté. J'ai gdm : sudo gdm stop pareil. Des fois quand X est planté, ouvrir un nouveau serveur libère la console : sudo X :1 Xorg après interruption se plaint : Fatal server error: xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
ça faisait un petit moment qu'il était dans cet état là.
je reviens à ma table de process : je vois qu'il y a un Xorg qui traîne. Je cherche à le tuer pas moyen. Je reboote (sudo reboot depuis la connexion ssh, je me relogue (gdm) ça recommence (console bloquée idem, rien à l'écran, toujours bloquée après avoir tué le démon et l'économiseur d'écran ( qui n'es ni un process qui accède à internet style webcollage ni un qui bouffe du CPU ou de la mémoire) je termine la sesssion, j'arrête gdm (invoke-rc.d gdm stop) plus de process gdm mais la console bloquée. les magic keys fonctionnent alt+sys+k suffit à libérer la console je redémarre gdm et depuis plus de souci (xscreensaver lance normalement l'économiseur d'écran, la console ne se bloque pas...
-- 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
YBM wrote:
su -c halt ou sudo halt
Certes.
sudo reboot aussi.
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
YBM wrote:
su -c halt ou sudo halt
Certes.
sudo reboot aussi.
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
-- 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
sebas22 wrote:
Bonjour,
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é ;)
-- 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 wrote:
Bonjour,
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é ;)
--
All truth passes through three stages :
First, it is ridiculed
Second, it is violently opposed
Third, it is accepted as being self-evident
Schopenhauer
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é ;)
-- All truth passes through three stages : First, it is ridiculed Second, it is violently opposed Third, it is accepted as being self-evident Schopenhauer
GuiGui
Yves Lambert a écrit :
GuiGui wrote:
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil qui consomme du CPU ?
Oui.
il faudrait un "ps fax" pour voir si c'est pas un fils qui bloque sur IO, sinon c'est directement le process qui attend ses IO. Venant de xorg, il se pourrait que ça soit un pb de deadlock du bus sur la video (bug driver ?).
Yves Lambert a écrit :
GuiGui wrote:
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil
qui consomme du CPU ?
Oui.
il faudrait un "ps fax" pour voir si c'est pas un fils qui bloque sur
IO, sinon c'est directement le process qui attend ses IO. Venant de
xorg, il se pourrait que ça soit un pb de deadlock du bus sur la video
(bug driver ?).
En y réfléchissant, c'est bizarre ce résultat : un process en sommeil qui consomme du CPU ?
Oui.
il faudrait un "ps fax" pour voir si c'est pas un fils qui bloque sur IO, sinon c'est directement le process qui attend ses IO. Venant de xorg, il se pourrait que ça soit un pb de deadlock du bus sur la video (bug driver ?).
