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.
# Re: Les processus immortels !
Posté par Obsidian . En réponse au journal Les processus immortels !. Évalué à 3.
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.