Une commande "cp" a bloqué le PC et impossible a tuer ce processus,
c'est donc toujours "busy". Impossible aussi de rebooter, shutdown
reste "defunct". updatedb, qui ce lance la nuit et lui aussi toujours
dans la liste des processus. Bref tout ce qui a acces a IDE1 reste
bloqué. Le PC est bien chargé "load average: 6.06, 5.55, 5.21" bien
que rien ne soit visible avec ps ou top.
Bonjour, le bouton marche/arrêt ne marche pas ? Ou sinon, la prise de courant. Reboot garanti sans condition ;-)
Cordialement.
Il faut lire les autres messages du thread avant de repondre!
GH
Ploc wrote:
Comment rebooter "en force" sans condition ?
meme avec : reboot -f ? reboot -f -n ? Dans tous les cas, un sync avant et un fsck apres sont recommandes. Mais il faudra probablement se deplacer (pour changer IDE1): ca me parrait bizarre qu'un simple cp provoque ca si tout va bien.
J'ai fait "shutdown -n" en oubliant, je crois car il n'y a aucune trace dans history, le -r... Mais quel connard je suis :(
Mais maintenant c'est arrangé :) shutdown -f n'avait rien donné.
Ploc wrote:
Comment rebooter "en force" sans condition ?
meme avec :
reboot -f ?
reboot -f -n ?
Dans tous les cas, un sync avant et un fsck apres sont recommandes.
Mais il faudra probablement se deplacer (pour changer IDE1): ca me
parrait bizarre qu'un simple cp provoque ca si tout va bien.
J'ai fait "shutdown -n" en oubliant, je crois car il n'y a aucune trace
dans history, le -r... Mais quel connard je suis :(
Mais maintenant c'est arrangé :) shutdown -f n'avait rien donné.
meme avec : reboot -f ? reboot -f -n ? Dans tous les cas, un sync avant et un fsck apres sont recommandes. Mais il faudra probablement se deplacer (pour changer IDE1): ca me parrait bizarre qu'un simple cp provoque ca si tout va bien.
J'ai fait "shutdown -n" en oubliant, je crois car il n'y a aucune trace dans history, le -r... Mais quel connard je suis :(
Mais maintenant c'est arrangé :) shutdown -f n'avait rien donné.
GH
Sébastien Monbrun aka TiChou wrote:
Dans le message <news:, *GH* tapota sur f.c.o.l.configuration, f.c.m.optimisation et f.c.s.pc :
Une commande "cp" a bloqué le PC et impossible a tuer ce processus, c'est donc toujours "busy". Impossible aussi de rebooter, shutdown reste "defunct". updatedb, qui ce lance la nuit et lui aussi toujours dans la liste des processus. Bref tout ce qui a acces a IDE1 reste bloqué. Le PC est bien chargé "load average: 6.06, 5.55, 5.21" bien que rien ne soit visible avec ps ou top.
C'est parce que des processus sont à l'état « ininterruptible » (colonne STAT, flag D) et que ces processus, qui en fait sont en attente et ne consomment à priori aucune ressource CPU, sont comptabilisés dans le calcul de la charge système.
Mais pourquoi il est impossible de les tuer?
Sébastien Monbrun aka TiChou wrote:
Dans le message <news:450c55F4bm23U1@individual.net>,
*GH* tapota sur f.c.o.l.configuration, f.c.m.optimisation et f.c.s.pc :
Une commande "cp" a bloqué le PC et impossible a tuer ce processus,
c'est donc toujours "busy". Impossible aussi de rebooter, shutdown
reste "defunct". updatedb, qui ce lance la nuit et lui aussi toujours
dans la liste des processus. Bref tout ce qui a acces a IDE1 reste
bloqué. Le PC est bien chargé "load average: 6.06, 5.55, 5.21" bien
que rien ne soit visible avec ps ou top.
C'est parce que des processus sont à l'état « ininterruptible » (colonne
STAT, flag D) et que ces processus, qui en fait sont en attente et ne
consomment à priori aucune ressource CPU, sont comptabilisés dans le
calcul de la charge système.
Dans le message <news:, *GH* tapota sur f.c.o.l.configuration, f.c.m.optimisation et f.c.s.pc :
Une commande "cp" a bloqué le PC et impossible a tuer ce processus, c'est donc toujours "busy". Impossible aussi de rebooter, shutdown reste "defunct". updatedb, qui ce lance la nuit et lui aussi toujours dans la liste des processus. Bref tout ce qui a acces a IDE1 reste bloqué. Le PC est bien chargé "load average: 6.06, 5.55, 5.21" bien que rien ne soit visible avec ps ou top.
C'est parce que des processus sont à l'état « ininterruptible » (colonne STAT, flag D) et que ces processus, qui en fait sont en attente et ne consomment à priori aucune ressource CPU, sont comptabilisés dans le calcul de la charge système.
Mais pourquoi il est impossible de les tuer?
Nicolas George
GH wrote in message :
Mais pourquoi il est impossible de les tuer?
Ces processus sont en espace noyau, dans un gestionnaire de périphérique, qui a des structures de données à absolument remettre en état quand il aura fini sa tâche. Les tuer ferait perdre cette remise en état.
GH wrote in message <4517v2F4dd67U2@individual.net>:
Mais pourquoi il est impossible de les tuer?
Ces processus sont en espace noyau, dans un gestionnaire de périphérique,
qui a des structures de données à absolument remettre en état quand il aura
fini sa tâche. Les tuer ferait perdre cette remise en état.
Ces processus sont en espace noyau, dans un gestionnaire de périphérique, qui a des structures de données à absolument remettre en état quand il aura fini sa tâche. Les tuer ferait perdre cette remise en état.
GH
[SauronDeMordor] wrote:
Le PC est a 80 km!
dans ces cas la on est cotent d avoir une prise d alim comandee sur ip.
je pense bricoler un reset par un optocoupleur sur une broche d'un port serie.
sinon j espere que tu a mis un console serie comme cela tu peux utiliser les magic sysrq puis rebooter et prendre la console et voir le boot.
si ton boot loader est grub tu a la main juste apres le bios ce qui te permet de faire de la maintenance meme si la prise rj45 est dow n
Oulla c'est compliqué pour moi!
[SauronDeMordor] wrote:
Le PC est a 80 km!
dans ces cas la on est cotent d avoir une prise d alim comandee sur ip.
je pense bricoler un reset par un optocoupleur sur une broche d'un port
serie.
sinon j espere que tu a mis un console serie comme cela tu peux utiliser
les magic sysrq puis rebooter et prendre la console et voir le boot.
si ton boot loader est grub tu a la main juste apres le bios ce qui te
permet de faire de la maintenance meme si la prise rj45 est dow
n
dans ces cas la on est cotent d avoir une prise d alim comandee sur ip.
je pense bricoler un reset par un optocoupleur sur une broche d'un port serie.
sinon j espere que tu a mis un console serie comme cela tu peux utiliser les magic sysrq puis rebooter et prendre la console et voir le boot.
si ton boot loader est grub tu a la main juste apres le bios ce qui te permet de faire de la maintenance meme si la prise rj45 est dow n
Oulla c'est compliqué pour moi!
GH
Nicolas George wrote:
GH wrote in message :
Mais pourquoi il est impossible de les tuer?
Ces processus sont en espace noyau, dans un gestionnaire de périphérique, qui a des structures de données à absolument remettre en état quand il aura fini sa tâche. Les tuer ferait perdre cette remise en état.
Et a terme ils ne se seraient pas "suicidé" tout seuls?
Nicolas George wrote:
GH wrote in message <4517v2F4dd67U2@individual.net>:
Mais pourquoi il est impossible de les tuer?
Ces processus sont en espace noyau, dans un gestionnaire de périphérique,
qui a des structures de données à absolument remettre en état quand il aura
fini sa tâche. Les tuer ferait perdre cette remise en état.
Et a terme ils ne se seraient pas "suicidé" tout seuls?
Ces processus sont en espace noyau, dans un gestionnaire de périphérique, qui a des structures de données à absolument remettre en état quand il aura fini sa tâche. Les tuer ferait perdre cette remise en état.
Et a terme ils ne se seraient pas "suicidé" tout seuls?
Nicolas George
GH wrote in message :
Et a terme ils ne se seraient pas "suicidé" tout seuls?
En temps normal, l'état D dure très peu de temps, le temps que le péripérique réponde, et ensuite le processus reprend son cours normal.
GH wrote in message <4518o3F4faeiU1@individual.net>:
Et a terme ils ne se seraient pas "suicidé" tout seuls?
En temps normal, l'état D dure très peu de temps, le temps que le
péripérique réponde, et ensuite le processus reprend son cours normal.
Et si le perif ne repond pas il n'y a aucun garde fous prevu? Ca peut durer des siecles? :)
On appelle ça un bug.
Emmanuel Fleury
Nicolas George wrote:
On appelle ça un bug.
Ou une "feature". :)
Amicalement -- Emmanuel Fleury
It really is a nice theory. The only defect I think it has is probably common to all philosophical theories. It's wrong. -- Saul Kripke (Naming and Necessity)
Nicolas George wrote:
On appelle ça un bug.
Ou une "feature". :)
Amicalement
--
Emmanuel Fleury
It really is a nice theory. The only defect I think it has is probably
common to all philosophical theories. It's wrong.
-- Saul Kripke (Naming and Necessity)
It really is a nice theory. The only defect I think it has is probably common to all philosophical theories. It's wrong. -- Saul Kripke (Naming and Necessity)
