Journal Les processus immortels !

Posté par  (site web personnel, Mastodon) .
Étiquettes :
0
27
oct.
2003
Depuis que je suis sur un 2.6test (7 puis 8), j'ai un GROS problème.

Le problème est généralement lié à esd.

En fait, une application utilisant du son plante (je ne sais pas laquelle) et tous les process demandant du son par après deviennent inkillable !

Ainsi esd, puis des xmms, gltron et compagnie refusent de fonctionner : pour cause, il y'a toujours un process à leur nom qui est inkillable.
Seule exception : les esdplay issu de mon client Jabber. Ils remplissent la liste des processus et un simple killall esdplay nettoie tout.

Même en tuant tout ce qu'il est possible de tuer, ces process restent là, jusqu'au prochain reboot. (ennuyant..)

Pire : le simple affichage de ces processus (genre un cat /proc/xxxx ) voire, dans le pire des cas, un ps -e gèle complètement la console où a été appelé la commande ! (j'ai eu le coup en lisant un fichier vidéo visiblement mal encodé avec totem )

Cela me semble tout de même énorme et, si il s'agit un bug de mon noyau, d'une grave faille.

Quelqu'un a t'il déjà eu ce genre de problème ? Une idée qqn ? Dois-je faire un repport de bug ? (et si oui, comment ? ce serait mon premier kernel bug !)

Je pense en effet qu'il s'agit de qqch d'important car je trouve très grave qu'un utilisateur puisse bloquer tout le PC sans que root ne puisse rien faire..
(note: ces processus fantomes sont en Sleep permanent, du moins pour ceux auxquels j'ai accès au répertoire proc )

  • # Re: Les processus immortels !

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

    ...même avec un kill -9 ?
    si tes processes sont des zombies, c'est normal, laisse-les zombifier...

  • # Re: Les processus immortels !

    Posté par  . Évalué à 3.

    La vache, un PS qui freeze ta session ? C'est violent ...
    Tes process sont en state "D", je suppose ? Il n'y a pas beaucoup de doc la-dessus, mais cela m'est déjà arrivé avec des noyaux 2.2.x et 2.4.x . Spécialement avec Netscape.

    Un admin m'a dit un jour que cela arrivait souvent sur les accès aux fichiers, et qu'il fallait attendre que le kernel finisse ce qu'il doit faire, donc, je suppose que cela arrive lorsque le kernel fait une opération « atomique » sur ton processus mais qu'il attend quand même quelque chose de l'extérieur. Cela arrive typiquement avec les I/O. Tu dois pouvoir prendre un "D" lorsque tu tues un processus qui avait ouvert des fichiers au travers d'un NFS, par exemple, et que celui-ci n'est plus accessible. Le kernel va essayer de nettoyer tout ce qui a été laissé en plan par le processus, notament fermer les fichiers, mais cette opération est l'initiative du noyau, et pas celle du processus, censé être mort, et qui ne peut donc plus recevoir aucun code de retour. Si le NFS est down, le VFS va attendre ad vitam aeternam la réponse des couches de plus bas niveau (en tout cas, jusqu'à un timeout du VFS), ce qui veut dire que c'est le kernel lui-même qui ne rend plus la main. Cela doit aussi arriver sur des périphériques lents alors qu'ils ne sont pas censés l'être (lecture sur un CD rayé, par exemple). Je suppose qu'il doit également y avoir moyen de provoquer des deadlocks entre des tubes ou des sockets.

    Bon tout cela est très hypothétique. C'est peu documenté car cela ne devrait pas arriver. Je m'en vais potasser les sources du noyau pour voir si je trouve plus d'infos.

    En tout cas, la moralité de l'histoire est que lorsque cela arrive, la première chose à faire est d'essayer de trouver ce qui bloque ton processus, et le premier endroit où regarder est /proc/fd, qui contient les descripteurs de tous les fichiers ouverts par le processus.

    Bon courage.

    • [^] # Re: Les processus immortels !

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

      cela ressemble en effet à chaque fois à un deadlock des applis utilisant esd.

      Les programmes bloqués et esd semblent normaux (plein de sockets ouverts, rien de très particuliers)

      Un simple message (logique) :

      ALSA lib pcm_hw.c:1055:(snd_pcm_hw_open) open /dev/snd/pcmC0D0p failed: Device or resource busy

      Ah, le Stdin de esd est /dev/null mais je suppose que c'est normal...

      Si tu veux, n'hésite pas à me contacter pour faire plus de tests, tu es sans doute plus callé que moi pour faire un bon rapport de bug ou même proposer une solution.

      Mes livres CC By-SA : https://ploum.net/livres.html

  • # Re: Les processus immortels !

    Posté par  . Évalué à 1.

    Esd a ete fait a la base pour OSS avec un semblant de support pour alsa 0.5.
    Le noyau 2.6 aime pas du tout esd, mais il s'en sort, sauf si bien sur Gnome2.4 s'en mele a coup d'appels GTK2 farfelus.
    J'avais le meme probleme, le mieux est de recompiler tes applis (xmms notamment) sans le support ESD. Ca marche vachement mieux apres.

    Kha

    • [^] # Re: Les processus immortels !

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

      Mais si on a quand même envie d'utiliser esd, on fait comment ? J'aime avoir mes notifications de message en écoutant de la musique.

      Mes livres CC By-SA : https://ploum.net/livres.html

      • [^] # Re: Les processus immortels !

        Posté par  . Évalué à 1.

        On compile sans le support, et on prie pour que le melangeur emule par alsa se vautre pas.
        ESD (ou meme ARTS) sont encore tres instables.

        Kha

  • # Re: Les processus immortels !

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

    mais enfin ? pourquoi je vois 5 commentaires sur la page des journaux et ici j'en vois plus que 2 même après refresh ?

    Mes livres CC By-SA : https://ploum.net/livres.html

  • # cdrecord aussi!

    Posté par  . Évalué à 2.

    J'ai ce genre de problème avec un graveur moribond.
    Il en fonctionne presque plus, et souvent il se bloque avant même que la gravure commence (ça je le sais, car quand je récupère enfin le CD il est toujours gravable). Dans ces conditions le cdrecord est impossible à tuer.
    Parfois il se termine proprement (après plusieurs minutes, sur un timeout en scsi), parfois pas et il faut redémarrer (sinon il va me remplir le syslog de messages d'erreur inutiles, car répétés à l'infini, j'ai déjà eu un syslog de 100Mo!).

    J'ai aussi eu le même genre de problème avec un disque dur branché sur un contrôleur ide endomagé.

    Y a-t-il un moyen de le forcer à s'arrêter, genre forcer un timeout pour qu'au moins le processus se termine.
    Je vais de toute façon racheter un graveur, mais j'aimerais savoir s'il existe un moyen de terminer des programmes qui sont bloqués par un appel noyau qui ne se termine pas. Il n'y a vraiment que le redémarrage (parfois violent avec les sysrq) qui marche?

    • [^] # Re: cdrecord aussi!

      Posté par  . Évalué à 1.

      C'est un problème que j'ai rencontré souvent avec des CD deffectueux. Une des solutions les plus efficaces que je connaisse (peut-être la plus crado aussi) est de faire : "cdrecord -eject". Ton CD est ejecté sans préavis et dans la plupart des cas, le noyau libère les ressources qui lui étaient allouées (cela peut prendre plusieurs minutes).

      Bonne chance.

Suivre le flux des commentaires

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