Journal Tuer un prgramme qui ne veut rien savoir....

Posté par  (site web personnel) .
Étiquettes :
0
27
juil.
2003
Salut

Je suis sous Gnome sur une debian sid et de temps en temps il arrive qu'un prgramme (graphique) plante... là c'est par exemple le cas de sylpheed-claws...
Le hic est que je n'arrive pas à le tuer... j'ai essayé, en simple user et en root, tous les kill possible mais il est toujours là :(

quelqu'un à une petite idée du comment faire ?

  • # Re: Tuer un prgramme qui ne veut rien savoir....

    Posté par  (site web personnel) . Évalué à 5.

    Si il est en statut D, y'a rien à faire, soit il finit par se débloquer tout seul, soit il faut rebooter.

    • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

      Posté par  (site web personnel) . Évalué à 1.

      il es bien en status D :

      twidi 7579 0.0 4.7 25008 18168 ? D 11:58 0:03 sylpheed-claws

      je v regarder à quoi correspond ce status (je ne connais pas)

      • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

        Posté par  (site web personnel) . Évalué à 7.

        C'est simple c'est un processus qui ne peut pas être interrompu, même par un kill -9, donc si il ne sort pas tout seul de ce status, c'est reboot obligatoire.
        Plusieurs possibilités :
        - Bug dans le kernel (très peu probable si c'est un 2.4.x),
        - Un problème réseau ou plantage de la machine distante lors de la lecture d'un fichier sur le réseau,
        - Un problème de matos defectueux ou tout simplement un CD difficile à lire.

        • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

          Posté par  (site web personnel) . Évalué à 1.

          il (sylpheed-claws) a planté lors de la lecture d'un repertoire contenant pres de 3000 mails, repertoire qui ne lui pose aucun pbm d'habitude
          j'ai remarqué qu'il gèle aussi des que le mail depasse les 100 ko : kill et suppression du fichier/mail responsable à la main...
          mais cette fois rien a faire :(

        • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

          Posté par  . Évalué à 2.

          >Plusieurs possibilités :
          >- Bug dans le kernel (très peu probable si c'est un 2.4.x),
          Est ce que le 2.6 va régler/minimiser ces problèmes ? (parce qu'il y
          a des changements au niveau de la granularité des verrous, non ?)
          Et avec Le Hurd ?

          >- Un problème réseau ou plantage de la machine distante lors
          >de la lecture d'un fichier sur le réseau,
          C'est vrai que des fois, j'arrive pas à démonter un smb distant même
          avec umount -f et comme le montage n'est pas associé à un process
          alors reboot :-(

          >- Un problème de matos defectueux ou tout simplement un CD
          >difficile à lire.
          Donc tu veux dire qu'un process qui lit un cdrom pourrave peut
          rester dans les choux ? Plutôt gênant ça... (le retour de l'écran
          bleu !)

          • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

            Posté par  . Évalué à 2.

            Je trouve personnellement cette impossibilité de tuer certains process (notamment quand ça bloque les périphériques amovibles (ça m'est déjà arrivé plusieurs fois pour mon graveur), ou que ça bouffe toute la mémoire) vraiment inadmissible. Et je ne comprends pas qu'il n'y ait pas de solution (bon je ne sais pas programmer, alors c'est peut-être pour ça que je ne comprends pas).
            En tout cas, il ne vaut mieux pas que ça arrive quand on démontre Linux à des amis parce que sinon cela risque de les rendre réfractaires.

            Il n'y a vraiment aucune solution que le reboot pour killer les processus qui ont le status D ?

            • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

              Posté par  . Évalué à 2.

              En fait, il y a toujours officiellement un moyen. Le processus D est noté « Ininterruptible Sleep », mais on le voit aussi noté « Dying » parfois.

              C'est un peu au kernel ce que les Zombies sont au processus père. 9 fois sur 10, c'est dù à un problème de fichier. Si le kernel ne peut pas refermer les fichiers que ton processus a ouvert, il ne peut pas libérer ses ressources avant d'avoir fini.

              Il n'y généralement pas grand chose à faire, mais lorsque cela se produit, la première d'entre elle est de chercher ce qui le bloque (accès au fichier, état bas-niveau du périphérique, spécialement quand celui-ci est amovible).

            • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

              Posté par  (site web personnel) . Évalué à 0.

              Oui, ne pas lire de données sur un partage windows, avoir du matos fiable, et utiliser que les fonctionnalités du kernel éprouvées. Tu réduis de 99% le risque d'avoir des processus dans l'états D (d'après mon expérience en la matière ...).

          • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

            Posté par  (site web personnel) . Évalué à 2.

            Est ce que le 2.6 va régler/minimiser ces problèmes ? (parce qu'il y
            a des changements au niveau de la granularité des verrous, non ?)
            Et avec Le Hurd ?
            Aucune idée.

            C'est vrai que des fois, j'arrive pas à démonter un smb distant même
            avec umount -f et comme le montage n'est pas associé à un process
            alors reboot :-(
            Ca depends beaucoup de l'OS qui héberge le partage, depuis que je n'ai plus que des machines sous Linux, je n'ai plus jamais eu se problème.

            Donc tu veux dire qu'un process qui lit un cdrom pourrave peut
            rester dans les choux ? Plutôt gênant ça... (le retour de l'écran
            bleu !)
            En fait, ça dépend du matos, par exemple j'ai un lecteur de DVD qui apparement retente de lire le CD jusqu'a ce qu'il y arrive, et quand il n'y arrive pas, le processus qui lit reste dans l'état D, le seul moyen de le débloquer c'est d'utiliser l'ejection de secours, jamais eu ce problème avec le graveur ou avec un ancien HITACHI 16X (une petite merveille en ce qui concerne la tolérance aux erreurs). Faut pas accuser le kernel quand c'est le matos qui déconne.

    • [^] # Re: Tuer un prgramme qui ne veut rien savoir....

      Posté par  (site web personnel) . Évalué à 2.

      $ man ps
      [...]
      STAT État du processus. Le premier champ correspond à R (runnable) prêt
      à être exécuté, S (sleeping) endormi, D sommeil ininterruptible, T
      (traced) arrêté ou suivi, Z (zombie). Le second champ contient W
      si le processus n'a pas de pages résidentes. Le troisième champ
      contient N si le processus a une valeur de gentillesse positive
      (nice, champ NI).
      [...]
      Je ne peux pas croire que le reboot soit la seule solution...

  • # Re: Tuer un prgramme qui ne veut rien savoir....

    Posté par  (site web personnel) . Évalué à 1.

    Je me répond à moi-même, car j'ai fini par trouvé... xkill

    (je n'avais pas cherché avec les bons termes sous google ;))

  • # Re: Tuer un prgramme qui ne veut rien savoir....

    Posté par  (site web personnel) . Évalué à 2.

    Tu as regardé autour de ipcs et ipcrm si ton programme utilisait des semaphores ou un truc du genre et que ceux-ci n'étaient pas libérés

    JYL

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.