Bonjour,
sur une redhat 4 (2.6.9-78), lorsque je fais un ps (peu importe les options), le listing des processus commence puis s'arrête, sans rendre la main. Impossible ensuite de killer la commande, ou même de la placer en background via ctrl+Z, je ne peux que fermer mon terminal à la sauvage.
Une idée du problème ?
Merci !
PS : pour info, la commande w plante de la même manière...
# Autre commande
Posté par DLFP est mort . Évalué à 1.
Tu peux essayer la commande UMP à la place, même si je pense que ça sera probablement la même chose.
DLFP >> PCInpact > Numerama >> LinuxFr.org
# tracing
Posté par fcartegnie . Évalué à 2.
ps &
strace -p $!
au pire un gdb
[^] # Re: tracing
Posté par Pierre Carrier . Évalué à 1.
[^] # Re: tracing
Posté par Krunch (site web personnel) . Évalué à 3.
strace et gdb vont sans doute pas t'en apprendre plus que « ça bloque dans l'appel système stat() » (ou peut-être un autre mais je mise une cacahouéte sur stat()). Par contre, un sysrq-t va te permettre de voir dans quoi ça coince au niveau noyau. Donc "echo t > /proc/sysrq-trigger" et tu nous dit ce que tu vois dans les logs noyau concernant ce ps.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# probleme de disque dur il me semble
Posté par NeoX . Évalué à 4.
j'ai souvenir d'avoir eu un souci similaire avec des machines avec d'autres linux que RH.
de memoire c'etait un souci de disque dur en effet certains programmes utilisent le disque pour lire/ecrire des données avant de te les afficher.
# merci
Posté par cho7 (site web personnel) . Évalué à 1.
Re,
bon et bien je ne saurai jamais ce qu'il s'est passé, vu que nous avons finalement demander à rebooter le serveur, et que depuis tout va bien...
Merci à vous pour les réponses, je serai peut-être plus doué la prochaine fois pour diagnostiquer le problème.
[^] # Re: merci
Posté par netsurfeur . Évalué à 2.
Des commandes qui ne rendent pas la main même quand ont essaie de les interrompre ou de les tuer, ça n'arrive que si elles sont bloquées sur des E/S non interruptibles, généralement des accès disques ou NFS.
J'espère que tu trouveras une explication dans les logs.
La dernière fois que ça m'est arrivé, c'était un contrôleur RAID qui avait rendu l'âme...
[^] # Re: merci
Posté par briaeros007 . Évalué à 2.
si c'est le cas, l'état du processus est à "D", et pas à s ou r.
L'état du processus peut se voir sur top, ou avec un ps auxwww
Si le ps ne marche pas, dans ce cas tu peux essayer d'attaquer les fichiers dans /proc/<pid> pour avoir ce genre d'infos. Avantage, tu connais de facto le pid ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.