Forum Linux.redhat la commande PS ne rend plus la main et vautre ma session

Posté par (page perso) .
Tags : aucun
1
2
mar.
2011

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 (page perso) . É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 . Évalué à 2.

    ps &
    strace -p $!
    au pire un gdb

    • [^] # Re: tracing

      Posté par . Évalué à 1.

      # strace -fxvtto/var/tmp/ps.strace -s1024 ps
      
    • [^] # Re: tracing

      Posté par (page perso) . É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 . É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 (page perso) . É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 . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.