Re: OT: Máquinas zombies
El Sunday 27 January 2008 20:46:19 JAP escribió: Todo eso está sin novedad en el frente; junto con netstat es lo primero que probé. Estoy SEGURO que no está zombie, pero estoy queriendo saber de alguien que haya tenido el problema, cómo se dio cuenta, qué hizo, qué utiliza ahora para evitarlo, etcétera. Es decir, alimentar la paranoia. Yo he tenido varios en máquinas preparadas para hacer de honeypot. Las máquinas zombies con linux existen, por supuesto que sí. Generalmente se nota cuando hay un tráfico desmesurado que antes no existía. Si es tu caso, revisa qué causa ese tráfico, echa un vistazo a fondo en directorios temporales, generalmente cuando te cuelan un rootkit ni se molestan en borrar ficheros. Si puedes, desvía todo el tráfico a otro puerto del switch para analizarlo, o bien si pasa a través de otra máquina tcpdump es tu amigo. Si tienes serias sospechas de alguna intrusión jamás uses las herramientas de la misma máquina porque probablemente las hayan cambiado. -- BOFH excuse #144: Too few computrons available. signature.asc Description: This is a digitally signed message part.
OT: Máquinas zombies
La presente pregunta es, si se quiere, sumamente estúpida, pero mucho se le aclara al estúpido que le contestan. Por tema que no viene al caso, hace un mes que mi computadora está corriendo sin parar, cosa que nunca hice. Estoy tras un cortafuego de un modem router convenientemente configurado. Corro Debian lenny bien actualizado. La pregunta es... ¿cómo detecto si me han hecho vudú, o sea, si se convirtió en zombie? DUDO que lo sea, no veo nada raro en el tráfico de red ni sobre los procesos de la máquina. DUDO que lo sea, todo lo que san google dice es sobre windows. Pero... ¿hay registros de zombies linux? ¿cómos se detectan? Es difícil vivir sin un poco de paranoia. Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: Máquinas zombies
El 27/01/08, JAP [EMAIL PROTECTED] escribió: La presente pregunta es, si se quiere, sumamente estúpida, pero mucho se le aclara al estúpido que le contestan. Por tema que no viene al caso, hace un mes que mi computadora está corriendo sin parar, cosa que nunca hice. Estoy tras un cortafuego de un modem router convenientemente configurado. Corro Debian lenny bien actualizado. La pregunta es... ¿cómo detecto si me han hecho vudú, o sea, si se convirtió en zombie? DUDO que lo sea, no veo nada raro en el tráfico de red ni sobre los procesos de la máquina. DUDO que lo sea, todo lo que san google dice es sobre windows. Pero... ¿hay registros de zombies linux? ¿cómos se detectan? Es difícil vivir sin un poco de paranoia. Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] con pstree y top -- MrIX Linux user number 412793. http://counter.li.org/ las grandes obras, las sueñan los santos locos, las realizan los luchadores natos, las aprovechan los felices cuerdo, y las critican los inútiles crónicos, yo no fui, seguro que es mas inteligente.
Re: OT: Máquinas zombies
Cristian Mitchell escribió: El 27/01/08, JAP [EMAIL PROTECTED] escribió: La presente pregunta es, si se quiere, sumamente estúpida, pero mucho se le aclara al estúpido que le contestan. Por tema que no viene al caso, hace un mes que mi computadora está corriendo sin parar, cosa que nunca hice. Estoy tras un cortafuego de un modem router convenientemente configurado. Corro Debian lenny bien actualizado. La pregunta es... ¿cómo detecto si me han hecho vudú, o sea, si se convirtió en zombie? DUDO que lo sea, no veo nada raro en el tráfico de red ni sobre los procesos de la máquina. DUDO que lo sea, todo lo que san google dice es sobre windows. Pero... ¿hay registros de zombies linux? ¿cómos se detectan? Es difícil vivir sin un poco de paranoia. Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] con pstree y top Todo eso está sin novedad en el frente; junto con netstat es lo primero que probé. Estoy SEGURO que no está zombie, pero estoy queriendo saber de alguien que haya tenido el problema, cómo se dio cuenta, qué hizo, qué utiliza ahora para evitarlo, etcétera. Es decir, alimentar la paranoia. En google no hay casi nada. Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: Máquinas zombies
On 27 ene, 14:50, JAP [EMAIL PROTECTED] wrote: Cristian Mitchell escribió: El 27/01/08, JAP [EMAIL PROTECTED] escribió: La presente pregunta es, si se quiere, sumamente estúpida, pero mucho se le aclara al estúpido que le contestan. Por tema que no viene al caso, hace un mes que mi computadora está corriendo sin parar, cosa que nunca hice. Estoy tras un cortafuego de un modem router convenientemente configurado. Corro Debian lenny bien actualizado. La pregunta es... ¿cómo detecto si me han hecho vudú, o sea, si se convirtió en zombie? DUDO que lo sea, no veo nada raro en el tráfico de red ni sobre los procesos de la máquina. DUDO que lo sea, todo lo que san google dice es sobre windows. Pero... ¿hay registros de zombies linux? ¿cómos se detectan? Es difícil vivir sin un poco de paranoia. Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] con pstree y top Todo eso está sin novedad en el frente; junto con netstat es lo primero que probé. Estoy SEGURO que no está zombie, pero estoy queriendo saber de alguien que haya tenido el problema, cómo se dio cuenta, qué hizo, qué utiliza ahora para evitarlo, etcétera. Es decir, alimentar la paranoia. En google no hay casi nada. Javier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] igual yo, me sucedio lo mismo le pase. el rkhunter, revise logs, pero a veces cuando la hacen la hacen bueno seria tener configurado un tripwire, para despejar cualquier duda, y descartar otras cosas un tcpdump para ver conexiones sospechosas Bueno por lo que es yo, me baje el debian y lo volvi a instalar, si fuera un server ahi esta la cosa tomar todas las precauciones del caso Saludos Saludos
Re: OT: Máquinas zombies
JAP escribió: Cristian Mitchell escribió: El 27/01/08, JAP [EMAIL PROTECTED] escribió: La pregunta es... ¿cómo detecto si me han hecho vudú, o sea, si se convirtió en zombie? con pstree y top Todo eso está sin novedad en el frente; junto con netstat es lo primero que probé. Estoy SEGURO que no está zombie, pero estoy queriendo saber de alguien que haya tenido el problema, cómo se dio cuenta, qué hizo, qué utiliza ahora para evitarlo, etcétera. Mas allá de si los end-user linuxeros somos o no un target para las botnet (;)), si alguien entró en tu máquina como root entonces la única forma de asegurarte que el equipo no se encuentra comprometido es desde otro; si una persona planea usar tu equipo como zombie, y hace un buen trabajo, entonces hay que asumir que, por ejemplo, pstree es en realidad un versión parcheada para que no liste los procesos que el atacante no quiera que se listen. Lo mismo con las demás utilidades de sistema. Lo que haría en tu caso, si realmente tenés dudas, es un backup y un cat /dev/urandom /dev/sdN. Claro, con un backup de /home y otro de /etc me puede llevar 3 horas tener un Debian nuevo, en mi pc personal, pero si lo que buscas es investigar entonces podrías snifear las conexiones con otro equipo, o usar un live cd para revisar los logs (posiblemente sin encontrar nada) y correr un md5 sobre los binarios del sistema para compararlos con otros seguros. No soy un experto en seguridad pero son las dos opciones que se me ocurren. Saludos! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OT: Máquinas zombies
Nico wrote: JAP escribió: Cristian Mitchell escribió: El 27/01/08, JAP [EMAIL PROTECTED] escribió: La pregunta es... ¿cómo detecto si me han hecho vudú, o sea, si se convirtió en zombie? con pstree y top Todo eso está sin novedad en el frente; junto con netstat es lo primero que probé. Estoy SEGURO que no está zombie, pero estoy queriendo saber de alguien que haya tenido el problema, cómo se dio cuenta, qué hizo, qué utiliza ahora para evitarlo, etcétera. Mas allá de si los end-user linuxeros somos o no un target para las botnet (;)), si alguien entró en tu máquina como root entonces la única forma de asegurarte que el equipo no se encuentra comprometido es desde otro; si una persona planea usar tu equipo como zombie, y hace un buen trabajo, entonces hay que asumir que, por ejemplo, pstree es en realidad un versión parcheada para que no liste los procesos que el atacante no quiera que se listen. Lo mismo con las demás utilidades de sistema. Lo que haría en tu caso, si realmente tenés dudas, es un backup y un cat /dev/urandom /dev/sdN. Claro, con un backup de /home y otro de /etc me puede llevar 3 horas tener un Debian nuevo, en mi pc personal, pero si lo que buscas es investigar entonces podrías snifear las conexiones con otro equipo, o usar un live cd para revisar los logs (posiblemente sin encontrar nada) y correr un md5 sobre los binarios del sistema para compararlos con otros seguros. No soy un experto en seguridad pero son las dos opciones que se me ocurren. Saludos! Buenos días, el aporte que puedo hacer al hilo por mi experiencia en este tema de la paranoia es el siguiente: Dando por hecha la suposición del amigo Nico sobre si alguien entró en tu máquina como root y parcheó herramientas como netstat, pstree o cualquier otra herramienta de administración, lo bueno sería que (habiendo sido precavidos) hubiésemos hecho chequeos md5 de las herramientas y directorios mas importantes de nuestro sistema (justo después de la instalación para mayor seguridad), guardando los resultados para cotejarlos luego en un supuesto caso como este contra los resultados del nuevo chequeo md5 que haríamos a las herramientas aparentemente modificadas. Obviamente el archivo de texto resultante lo deberíamos guardar en un medio ajeno a la propia máquina por cuestiones de seguridad. Si los resultados de la comparación con el md5 actual de las herramientas no coincidiesen, existen detectores de rootkits que podemos utilizar para detectar esa clase de anomalías. La siguiente dirección corresponde a check rootkit, el detector de rootkits mas popular, capaz también de realizar chequeos sobre varios aspectos de la seguridad del sistema, incluyendo la modificación de binarios del sistema: http://www.chkrootkit.org Creo que eso es todo lo que pudiera aconsejar. Saludos. Martín
Re: OT: Máquinas zombies
El 27/01/08, Martín Peluso [EMAIL PROTECTED] escribió: Nico wrote: JAP escribió: Cristian Mitchell escribió: El 27/01/08, JAP [EMAIL PROTECTED] escribió: La pregunta es... ¿cómo detecto si me han hecho vudú, o sea, si se convirtió en zombie? con pstree y top Todo eso está sin novedad en el frente; junto con netstat es lo primero que probé. Estoy SEGURO que no está zombie, pero estoy queriendo saber de alguien que haya tenido el problema, cómo se dio cuenta, qué hizo, qué utiliza ahora para evitarlo, etcétera. Mas allá de si los end-user linuxeros somos o no un target para las botnet (;)), si alguien entró en tu máquina como root entonces la única forma de asegurarte que el equipo no se encuentra comprometido es desde otro; si una persona planea usar tu equipo como zombie, y hace un buen trabajo, entonces hay que asumir que, por ejemplo, pstree es en realidad un versión parcheada para que no liste los procesos que el atacante no quiera que se listen. Lo mismo con las demás utilidades de sistema. Lo que haría en tu caso, si realmente tenés dudas, es un backup y un cat /dev/urandom /dev/sdN. Claro, con un backup de /home y otro de /etc me puede llevar 3 horas tener un Debian nuevo, en mi pc personal, pero si lo que buscas es investigar entonces podrías snifear las conexiones con otro equipo, o usar un live cd para revisar los logs (posiblemente sin encontrar nada) y correr un md5 sobre los binarios del sistema para compararlos con otros seguros. No soy un experto en seguridad pero son las dos opciones que se me ocurren. Saludos! Buenos días, el aporte que puedo hacer al hilo por mi experiencia en este tema de la paranoia es el siguiente: Dando por hecha la suposición del amigo Nico sobre si alguien entró en tu máquina como root y parcheó herramientas como netstat, pstree o cualquier otra herramienta de administración, lo bueno sería que (habiendo sido precavidos) hubiésemos hecho chequeos md5 de las herramientas y directorios mas importantes de nuestro sistema (justo después de la instalación para mayor seguridad), guardando los resultados para cotejarlos luego en un supuesto caso como este contra los resultados del nuevo chequeo md5 que haríamos a las herramientas aparentemente modificadas. Obviamente el archivo de texto resultante lo deberíamos guardar en un medio ajeno a la propia máquina por cuestiones de seguridad. Si los resultados de la comparación con el md5 actual de las herramientas no coincidiesen, existen detectores de rootkits que podemos utilizar para detectar esa clase de anomalías. La siguiente dirección corresponde a check rootkit, el detector de rootkits mas popular, capaz también de realizar chequeos sobre varios aspectos de la seguridad del sistema, incluyendo la modificación de binarios del sistema: http://www.chkrootkit.org Creo que eso es todo lo que pudiera aconsejar. Saludos. Martín En mi caso que me paso. el problema fue una libreria que instale para opera. se ponia a prosesar como loca. si la maquina se te pone a prosesar a full en general tenes que olvidar la red. a menos que denotes una actividad inusual. en mi experiencia la paranoia para lo unico que sirve es para no encontrar el problema, es muy mala consegera, es tan comun el error humano, y mas en linux. los dos comandos que te puse en el mail anterior son para ver los prosesos de la maquina, y cuanta memoria se utiliza para los mismos. si no son demasiado el problema puede ser se swap o memoria -- MrIX Linux user number 412793. http://counter.li.org/ las grandes obras, las sueñan los santos locos, las realizan los luchadores natos, las aprovechan los felices cuerdo, y las critican los inútiles crónicos, yo no fui, seguro que es mas inteligente.
zombies when running swatch via start-stop-daemon --chuid
Under etch I'm using start-stop-daemon to start the swatch log monitoring utility in an /etc/init.d script. This is working, but each instance of swatch (I'm starting multiple -- one instance per monitored log) creates a zombie process the first time it logs something. I'm using the '--chuid' option of start-stop-daemon so that I can run as a unprivileged user, and if I take that option away then I don't get the zombies. In my swatch configuration I'm doing an 'exec' action, so maybe that's part of the problem. If the problem is the '--chuid' option, then is there another way I can get swatch running as a unprivileged user when the system boots? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lots of zombies with Mozilla, MozillaFirebird or psi
I had lots of Zombie processes lastly on my debian sid box and can't find the problem. Does somebody run into similar problems with wrong preferences or something? The following programs causing zombie processes: Mozilla: 1.6-1 PSI: 0.9-2 MozillaFirebird (Nightly Build): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040127 Firebird/0.8.0+ Rhythmbox: 0.6.5-1 Are there some tools, to look what happens with the program and which causes these zombie processes? Maybe something like: garlic ;) Thanks, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: top --zombies
hendrickx guy wrote: bonjour depuis hier quand je tape la commande top j'ai un processus zombie tout d'abord c'est quoi exactement un prosecus zombie command savoir qui c'est et comment regler cela Bonjour, Pour une réponse sur ce qu'est un zombie voir ici : http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC14 (merci google.. ;-) ) La solution vient naturellement avec l'explication : il faut tuer le père du Zombie. Si par malheur le père est init, la seule solution est à ma connaissance le reboot. En espérant aider, Denis.
Re: top --zombies
On Sun, Jun 29, 2003 at 11:39:46AM +0200, Alain Tesio wrote: On 28 Jun 2003 19:00:29 +0200 hendrickx guy [EMAIL PROTECTED] wrote: depuis hier quand je tape la commande top j'ai un processus zombie tout d'abord c'est quoi exactement un prosecus zombie Le kernel garde la liste des processus terminés avec leur statut d'exécution tant que leur parent ne l'a pas demandé. Si le parent se termine ou est killé avant de demander le code de retour, le fils devient zombie. Je n'en suis pas sûr. Tout processus se terminant devrait passer par l'état zombi et y rester jusqu'à ce que son père prenne connaissance de sa terminaison. Si le père se termine avant d'avoir pris connaissance de cette terminaison, le zombi devrait être adopté par le processus numéro 1 (init) qui est avisé que son fils adoptif est terminé et prend en compte cette terminaison (ce qui entraine la suppression du processus zombi). En tout cas, les choses se passent ainsi dans le monde Unix. On peut donc s'attendre à ce que soit pareil avec Linux... A mon avis, le père du zombi n'est pas terminé, mais quelque chose fait qu'il ne prend pas connaissance de la terminaison d'un de ses fils. command savoir qui c'est et comment regler cela Je crois que tu ne peux pas, mais ils ne consomment presque pas de ressources. Si je me souviens bien, un processus zombi ne consomme qu'une seule ressource : une entrée dans la table des processus. Pour te débarasser de tom zombi, une solution particulièrement brutale serait de tuer son père (champ PPID dans ps) avec un kill -9 par exemple mais avant de tuer le père, assure toi que les conséquences de sa mort ne seront pas pire que le mal. Bref, utilise ton jugement. A+ -- Jérôme
Re: top --zombies
On Sat, Jun 28, 2003 at 07:00:29PM +0200, hendrickx guy wrote: tout d'abord c'est quoi exactement un prosecus zombie Cf mail d'Alain, command savoir qui c'est et comment regler cela ps faux te dira qui est le père du zombie. C'est un bug de l'application, ne pas hésiter à le faire remarquer à l'auteur (ou mainteneur ou autre responsable). /Y -- Marbles should be kept together.
init le maitre [était Re: top --zombies]
Le Sat Jun 28 2003 à 07:00:29PM +0200, hendrickx guy ecrivit : bonjour depuis hier quand je tape la commande top j'ai un processus zombie init récupère le processus fils quand le père est tué. Après il exécute régulièrement wait () pour terminer proprement le fils. tout d'abord c'est quoi exactement un prosecus zombie D'autres ont répondus command savoir qui c'est et comment regler cela par le nom et la date de naissance du processus, après une bonne soupe de neurones ... David Dumortier.
Re: top --zombies
Le 12232ième jour après Epoch, Denis Rampnoux écrivait: hendrickx guy wrote: bonjour depuis hier quand je tape la commande top j'ai un processus zombie tout d'abord c'est quoi exactement un prosecus zombie command savoir qui c'est et comment regler cela Bonjour, Pour une réponse sur ce qu'est un zombie voir ici : http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC14 (merci google.. ;-) ) La solution vient naturellement avec l'explication : il faut tuer le père du Zombie. Si par malheur le père est init, la seule solution est à ma connaissance le reboot. Pas vrai, il me semble. Dans ce cas, init est gentil et il va voir de temps en temps quels sont ses fils adoptifs (g) et demande leur statut. Ainsi les process zombies finissent pas disparaître tout seuls. J'avoue ne pas avoir regardé dans le code de 'init', pour affirmer ça, mais bon c'est à toi de le faire là :) -- Your mind understands what you have been taught; your heart, what is true. -- François TOURDE - tourde.org - 23 rue Bernard GANTE - 93250 VILLEMOMBLE Tél: 01 49 35 96 69 - Mob: 06 81 01 81 80 eMail: mailto:[EMAIL PROTECTED] - URL: http://francois.tourde.org/
Re: init le maitre [tait Re: top --zombies]
On Mon, Jun 30, 2003 at 03:51:13PM +0200, David Dumortier wrote: command savoir qui c'est et comment regler cela par le nom et la date de naissance du processus, après une bonne soupe de neurones ... Tiens, je viens de trouver une autre solution: cat /proc/pid/status | grep Ppid Il fallait bien que ps tienne l'info de qq part... /Y -- Marbles should be kept together.
Re: top --zombies
On 28 Jun 2003 19:00:29 +0200 hendrickx guy [EMAIL PROTECTED] wrote: depuis hier quand je tape la commande top j'ai un processus zombie tout d'abord c'est quoi exactement un prosecus zombie Le kernel garde la liste des processus terminés avec leur statut d'exécution tant que leur parent ne l'a pas demandé. Si le parent se termine ou est killé avant de demander le code de retour, le fils devient zombie. command savoir qui c'est et comment regler cela Je crois que tu ne peux pas, mais ils ne consomment presque pas de ressources. Alain
top --zombies
bonjour depuis hier quand je tape la commande top j'ai un processus zombie tout d'abord c'est quoi exactement un prosecus zombie command savoir qui c'est et comment regler cela -- hendrickx guy [EMAIL PROTECTED]
Re: signify und Zombies
On Tue, Feb 11, 2003 at 12:19:54AM +0100, Jens Kubieziel wrote:
ich nutze signify, um zufällige Signaturen zu generieren. U.a. habe ich
eine eigene Zitatedatei, die mit eingebunden werden soll. Diese Datei
liegt, wie von der Manpage vorgeschlagen, in
/usr/local/share/games/fortunes/. Signify schreibt mittels FIFO in
.signature (signify --fifo=/home/kubi/.signature
--input=/home/kubi/.signify).
Manchmal vergisst nun signify oder auch fortune das Zitat einzufügen.
Dann hat die Signatur das Muster Name Webseite und nicht, wie
gewollt NameWebseiteCRZitat. Nebenprodukt dieser Aktion ist dann
ein Zombie. Woran könnte dies liegen?
Ich habe mal strace eingesetzt, um etwas mehr zu sehen. Leider sagt mir
der Output eher nichts. Kann jemand von euch etwas herauslesen:
[...]
--- SIGCHLD (Child exited) ---
read(12, Erfahrung ist die Summe der Dumm..., 4096) = 108
read(12, , 4096) = 0
close(12) = 0
munmap(0x401c2000, 4096)= 0
rt_sigaction(SIGHUP, {SIG_IGN}, {0x80931f0, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGINT, {SIG_IGN}, {0x80931f0, [], SA_RESTART|0x400}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {0x80931f0, [], SA_RESTART|0x400}, 8) = 0
wait4(10182, [WIFEXITED(s) WEXITSTATUS(s) == 0], 0, NULL) = 10182
rt_sigaction(SIGHUP, {0x80931f0, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x80931f0, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x80931f0, [], SA_RESTART|0x400}, NULL, 8) = 0
fstat64(3, {st_mode=S_IFIFO|0644, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401c2000
write(3, Jens Kubieziel ..., 181) = 181
close(3)= 0
munmap(0x401c2000, 4096)= 0
utime(/home/kubi/.signature, [1996/08/14-07:20:00, 1996/08/14-07:20:00]) = 0
time([1045667187]) = 1045667187
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0}) = 0
time([1045667188]) = 1045667188
utime(/home/kubi/.signature, [1996/08/14-07:20:00, 1996/08/14-07:20:00]) = 0
open(/home/kubi/.signature, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3
fstat64(3, {st_mode=S_IFIFO|0644, st_size=0, ...}) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
pipe([12, 13]) = 0
pipe([14, 15]) = 0
fork() = 10205
close(13) = 0
close(15) = 0
read(14, 0xb3e8, 4) = ? ERESTARTSYS (To be restarted)
--- SIGCHLD (Child exited) ---
read(14, \2\0\0\0, 4) = 4
close(14) = 0
fstat64(3, {st_mode=S_IFIFO|0644, st_size=0, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401c2000
write(3, Jens Kubieziel ..., 73) = 73
close(3)= 0
munmap(0x401c2000, 4096)= 0
utime(/home/kubi/.signature, [1996/08/14-07:20:00, 1996/08/14-07:20:00]) = 0
time([1045667415]) = 1045667415
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, {1, 0}) = 0
time([1045667416]) = 1045667416
utime(/home/kubi/.signature, [1996/08/14-07:20:00, 1996/08/14-07:20:00]) = 0
open(/home/kubi/.signature, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666
[...]
--
Jens Kubieziel http://www.kubieziel.de
Tatsachen stehen in der Politik oft nicht hoch im Kurs. Selbst
hartnäckige Misserfolge gelten noch als Beweis fuer die Richtigkeit der
Theorie. (Helmar Nahr)
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
signify und Zombies
Hallo,
ich nutze signify, um zufällige Signaturen zu generieren. U.a. habe ich
eine eigene Zitatedatei, die mit eingebunden werden soll. Diese Datei
liegt, wie von der Manpage vorgeschlagen, in
/usr/local/share/games/fortunes/. Signify schreibt mittels FIFO in
.signature (signify --fifo=/home/kubi/.signature
--input=/home/kubi/.signify).
Manchmal vergisst nun signify oder auch fortune das Zitat einzufügen.
Dann hat die Signatur das Muster Name Webseite und nicht, wie
gewollt NameWebseiteCRZitat. Nebenprodukt dieser Aktion ist dann
ein Zombie. Woran könnte dies liegen?
Die Zitatdatei hat das Muster:
Zitat 1
%
Zi
tat
2
%
Zitat3 usw.
%
kubi@QBI050102:~$ cat .signify
% $SIGWIDTH= 72
% $http=http://www.kubieziel.de
% $name=Jens Kubieziel
% ( left,minwidth
$name
% |
% | right,minwidth
$http
% )
% { exec
/usr/games/fortune.en -a -n 160 -s
% | exec
/usr/games/spruch -a -n 160 -s
% | exec
/usr/games/fortune /usr/local/share/games/fortunes/zitate-jens
% }
kubi@QBI050102:~$ ps aux | grep Z
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
kubi 14577 0.0 0.0 00 pts/0ZFeb10 0:00 [signify
defunct]
kubi 14579 0.0 0.0 00 pts/0ZFeb10 0:00 [signify
defunct]
[...]
--
Jens Kubieziel http://www.kubieziel.de
In New York, in einer Nebengasse, wollte ich eigentlich nur eine Cola kaufen.
-- Nils Magnus
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
normal that with kernel 2.4.20 i ahve lots of zombies??
Hello! i jsut rebootet my machine with a standard 2.4.20-k7 and now i have ltos of programs that crash and are unremovable since definitely zombified what's going wrong here? -- ciao bboett == [EMAIL PROTECTED] http://inforezo.u-strasbg.fr/~bboett === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processus zombies (était Processus 'non killable')
Soir la liste [snipall] si je me rappelle bien, un zombie attend juste que ses fils se terminent donc il faut killer tout ses descendants. ça devrait suffire. Nop c'est le contraire (cf. man ps l 220-223), ce sont des fils qui attendent un appel système wait (man 2 wait) du popa. cynique Si il est mort les orphelins sont envoyés à l'institut init qui les piquera comme à la SPA au bout d'un certain temps. /cynique Bon je vais me faire un chocolat je deviens bileux :-) David Dumortier Le plaisir des morts est de moisir à plat. R. Desnos Le plaisir des plats est de ne pas moisir à mort
viele Zombies - kein fork mehr
Hi miteinander! Ich hab zwischendurch mal das Problem, das nix mehr geht (nicht mal mehr ein kill), da keine fork mehr geht (resource not available). Wenn man denn dann mal ein ps aux absetzen kann, sieht man folgendes ziemlich oft: dh6116 0.0 0.0 00 ?Z02:48 0:00 [java defunct] Besonders oft sind es java oder Gnome-Programme wie galeon und evolution, die ne Menge dieser Zombies produziert. Wie kommt das und was kann man dagegen tun? So kann mal jedenfalls nicht arbeiten, heute hatte ich die Situation bestimmt 3-4 mal :( /dirk -- Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Help! - ppp zombies
~ Hello world, Of late I'm getting spurious ppp entries shown by ifconfig. It happens when a modem goes down. It might have been ppp3 but it comes up again as pppx, where x is the next unused number and ppp3 becomes a zombie. Right now I have two zombies, shown here with a valid entry in the middle. ppp1 Link encap:Point-to-Point Protocol UP POINTOPOINT RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1 RX packets:28980 errors:0 dropped:0 overruns:0 frame:0 TX packets:27862 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:5 ppp2 Link encap:Point-to-Point Protocol inet addr:203.91.66.225 P-t-P:203.91.65.14 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1 RX packets:15182 errors:0 dropped:0 overruns:0 frame:0 TX packets:9526 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:5 ppp3 Link encap:Point-to-Point Protocol UP POINTOPOINT RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1 RX packets:2991 errors:0 dropped:0 overruns:0 frame:0 TX packets:8593 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:5 I have:- changed kernels (2.2.17 - 2.2.18) upgraded ppp(v2.3 - v2.4) but the problem persists. As a result I often get a significant percentage of lost packets - sometimes over 50%. As you can see, I am using eql here but it has worked perfectly for years and has not been fiddled with. The only way I have found of putting things right is a reboot. I am at a complete loss as to how to tackle this one. Anyone? Lindsay -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lindsay Allen [EMAIL PROTECTED]Perth, Western Australia voice +61 8 9316 2486, 0403 272 564 32.0125S 115.8445E Debian Linux =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
zombies
Hi all Today I noticed the following: 15444 ? Z0:00 (cron zombie) Under which circumstances does a process turn into a zombie? I assume this applies to UNIX in general. Any pointers / references appreciated. TIA Sven
Re: zombies
Sven Burgener wrote: ... Today I noticed the following: 15444 ? Z0:00 (cron zombie) Under which circumstances does a process turn into a zombie? I assume this applies to UNIX in general. zombies are what is left from child processes when the parents thereof do not wait() for them, but exit() instead. Any pointers / references appreciated. http://support.qnx.com/support/docs/qnx4/sysarch/proc.html has another wording. TIA YWIA
Re: zombies
Today I noticed the following: 15444 ? Z0:00 (cron zombie) Under which circumstances does a process turn into a zombie? I assume this applies to UNIX in general. zombies are what is left from child processes when the parents thereof do not wait() for them, but exit() instead. that's wrong ... if the parent process would exit, then it's children would be inherited by init, which would make a wait() upon the sigchld it will receive, when the child exits. long-time zombies typically indicate a locked up parent process. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- If Windows is the answer, I want the problems back!
Re: zombies
Today I noticed the following: 15444 ? Z0:00 (cron zombie) Under which circumstances does a process turn into a zombie? I assume this applies to UNIX in general. zombies are what is left from child processes when the parents thereof do not wait() for them, but exit() instead. that's wrong ... if the parent process would exit, then it's children would be inherited by init, which would make a wait() upon the sigchld it will receive, when the child exits. long-time zombies typically indicate a locked up parent process. btw: for cron this is normal. it does not collect it's zombies very often. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- If Windows is the answer, I want the problems back!
Re: zombies
Bolan Meek wrote: Sven Burgener wrote: ... Today I noticed the following: 15444 ? Z0:00 (cron zombie) Under which circumstances does a process turn into a zombie? I assume this applies to UNIX in general. zombies are what is left from child processes when the parents thereof do not wait() for them, but exit() instead. Whoops: they are what is left from child processes if _they_ terminate without being wait()ed. Sorry for the confusion. I'm glad I read the link I passed along. Any pointers / references appreciated. http://support.qnx.com/support/docs/qnx4/sysarch/proc.html has another wording. BTW, I found this by requesting a search of 'zombie process' on http://www.google.com/search?q=num=100
Re: zombies
Oswald Buddenhagen wrote: Today I noticed the following: ... Under which circumstances does a process turn into a zombie? I assume this applies to UNIX in general. zombies are what is left from child processes when the parents thereof do not wait() for them, but exit() instead. that's wrong ... if the parent process would exit, then it's children would be inherited by init, which would make a wait() upon the sigchld it will receive, when the child exits. long-time zombies typically indicate a locked up parent process. Ah, yes. I'd caught myself, but you beat me to it: good work!
Re: zombies
On Mon, May 29, 2000 at 09:40:21PM +0200, Oswald Buddenhagen wrote: that's wrong ... if the parent process would exit, then it's children would be inherited by init, which would make a wait() upon the sigchld it will receive, when the child exits. long-time zombies typically indicate a locked up parent process. btw: for cron this is normal. it does not collect it's zombies very often. I'm also finding several (1-3, usually) zombie processes every few days. They are *always* associated with cron jobs. Not sure what the problem is, but I also had to split out some of my cron.daily and cron.weekly stuff to get everything to run. Any ideas for tracking down what's going wrong here? -- Karsten M. Self kmself@ix.netcom.com http://www.netcom.com/~kmself Evangelist, Opensales, Inc. http://www.opensales.org What part of Gestalt don't you understand? Debian GNU/Linux rocks! http://gestalt-system.sourceforge.net/ K5: http://www.kuro5hin.org GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0 pgpt29Y6a53wJ.pgp Description: PGP signature
Re: Zombies
On Fri, Mar 26, 1999 at 09:40:54PM -0800, Joey Hess wrote: Kent West wrote: Mine looks okay; well, other than it being a man page and I find most man pages ugly to begin with, but only because I speak English instead of Developer :) Have to agree with Brandon, it's completly broken. There _is_ no nroff formatting, they took a preformatted text file and stuck enough of a header on it so apropos works, but it's all preformatted. Nasty. Is this new in potato? I can't see this in the one on my slink systems. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: Zombies
Hello, Chris Brown: kill pid# did not work. Somewhere along the way the jobs attained the zombie status, and kill wouldn't touch them. I finally rebooted. Can someone explain what a zombie is and how to kill it? The idea is that when a process dies, gets killed or just exits, its parent must be notified; if this notification can't happen at once, the process is labelled `zombie'. When notification goes through, the zombie disappears. So basically it's being kept around for bookkeeping reasons. To get rid of a zombie, you can also kill the parent. HTH Jiri -- [EMAIL PROTECTED] We'll know the future has arrived when every mailer transparently quotes lines that begin with From , but no-one remembers why.
Re: Zombies
BTW, has anyone else noticed that the manpage for ps(1) is uglier than sin? Whose idea of nroff formatting is that? Mine looks okay; well, other than it being a man page and I find most man pages ugly to begin with, but only because I speak English instead of Developer :) (why don't they ever give real-life examples of the command instead of just techno-speak?) Okay- new question. When I tried to send this message I got an error from Netscape Messenger saying that I couldn't send it to Branden because the Administrator had prohibited it. AFAIK, I am the Administrator, and I don't recall ever prohibiting sending mail to anyone or anywhere. What gives?
Can't send-prohibited by Administrator (was Re: Zombies)
Kent West wrote: Okay- new question. When I tried to send this message I got an error from Netscape Messenger saying that I couldn't send it to Branden because the Administrator had prohibited it. AFAIK, I am the Administrator, and I don't recall ever prohibiting sending mail to anyone or anywhere. What gives? MORE INFO I changed my Netscape preferences so that my outgoing server was my ISP's server, and then I was able to send it. When it was set to localhost it didn't work, but I've never had any trouble before. Or have I sent any mail since installing Netscape? Hmmm, maybe I haven't; it's only been a few days, so that's possible. Anyone have any enlightment to share with me on this?
Re: Zombies
Kent West wrote: Mine looks okay; well, other than it being a man page and I find most man pages ugly to begin with, but only because I speak English instead of Developer :) Have to agree with Brandon, it's completly broken. There _is_ no nroff formatting, they took a preformatted text file and stuck enough of a header on it so apropos works, but it's all preformatted. Nasty. .\ This man page is a horrid hack because *roff sucks. .\ The whole system is way obsolete. The internal header .\ stuff must die, and will when I figure out how to kill it. .\ I've already killed the wasteful left margin and screwy .\ old perfect justification. Gross! You'd think someone .\ invented this crap in 1973. Oh yeah, they did. Sorry. Heh. (why don't they ever give real-life examples of the command instead of just techno-speak?) Good ones do. :-) -- see shy jo
RE: Can't send-prohibited by Administrator (was Re: Zombies)
On 27-Mar-99 Kent West wrote: Kent West wrote: Okay- new question. When I tried to send this message I got an error from Netscape Messenger saying that I couldn't send it to Branden because the Administrator had prohibited it. AFAIK, I am the Administrator, and I don't recall ever prohibiting sending mail to anyone or anywhere. What gives? Are you using Exim? -- Andrew [PGP5.0 Key ID 0x5EE61C37]
RE: Can't send-prohibited by Administrator (was Re: Zombies)
On 27-Mar-99 George Bonser wrote: On Sat, 27 Mar 1999, Pollywog wrote: Are you using Exim? He must be, Adminstrative Prohibition is the standard Exim wave off message. George Bonser Support The THING -- http://shorelink.com/~grep/THING.html I had the same problem with Netscape, and it was one of those Exim options you mentioned. -- Andrew [PGP5.0 KeyID 0x5EE61C37] [ICQ#175285]
Re: Can't send-prohibited by Administrator (was Re: Zombies)
George Bonser wrote: BTW, what does /var/log/exim/rejectlog give as a reason for rejecting the message? Support THING! (THing Is Not GNU). http://shorelink.com/~grep/THING.html 1999-03-26 22:57:34 refused relay (host reject) to [EMAIL PROTECTED] from [EMAIL PROTECTED] H=westk03 (nicanor.acu.edu) [127.0.0.1] (westk)
Re: Zombies
Package: procps Version: 1:1.9.0-2 Severity: wishlist On Fri, Mar 26, 1999 at 10:58:10PM -0600, Kent West wrote: BTW, has anyone else noticed that the manpage for ps(1) is uglier than sin? Whose idea of nroff formatting is that? Mine looks okay; well, other than it being a man page and I find most man pages ugly to begin with, but only because I speak English instead of Developer :) (why don't they ever give real-life examples of the command instead of just techno-speak?) It's not a man page at all. Especially, the author seems to be completely ignorant of any text formatiing system. Yeah, this is a bug report. ps (1) should be a man page formatted in the troff format. Thanks, Marcus .\ Man page for ps. .\ Quick hack conversion by Albert Cahalan, 1998. .\ Licensed under version 2 of the Gnu General Public License. .\ .\ This man page is a horrid hack because *roff sucks. .\ The whole system is way obsolete. The internal header .\ stuff must die, and will when I figure out how to kill it. .\ I've already killed the wasteful left margin and screwy .\ old perfect justification. Gross! You'd think someone .\ invented this crap in 1973. Oh yeah, they did. .\ .TH PS 1 July 5, 1998 Linux Linux User's Manual .SH \fRNAME\fR ps \- report process status .ad r .na .ss 12 0 .in 0 .nh .nf SYNOPSIS ps [options] DESCRIPTION ps gives a snapshot of the current processes. If you want a repetitive update of this status, use top or gtop. This man page documents the /proc-based version of ps, or tries to. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@ Marcus Brinkmann GNUhttp://www.gnu.org master.debian.org [EMAIL PROTECTED]for public PGP Key http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Zombies
I had a few cpio scripts running in background, noticed an error with one of my scripts (it was recursive) and tried to stop it. kill pid# did not work. Somewhere along the way the jobs attained the zombie status, and kill wouldn't touch them. I finally rebooted. Can someone explain what a zombie is and how to kill it? TIA, Chris * Chris Brown [EMAIL PROTECTED] !!! HELP FIGHT SPAM !!! Join; www.cauce.org See; spam.abuse.net, spamsucks.com, www.cm.org
Re: Zombies
On Fri, Mar 26, 1999 at 01:21:49PM -0500, Chris Brown wrote: I had a few cpio scripts running in background, noticed an error with one of my scripts (it was recursive) and tried to stop it. kill pid# did not work. Somewhere along the way the jobs attained the zombie status, and kill wouldn't touch them. I finally rebooted. Can someone explain what a zombie is and how to kill it? You cannot kill a zombie process, because it's already dead. A zombie process is the child of another process, its parent processes. A zombie is denoted by defunct in the process name listed by the ps command. A child becomes a zombie when its parent fails to wait for it to exit properly. Zombie processes do not consume CPU; the scheduler (in the kernel) ignores them. I am not sure if they can possess other resources, like memory or file descriptors; I was once told that they don't, but the manpage for wait(2) implies that they can use system resources. They do, obviously, fill up a slot in your process table, so if you have tens of thousands of zombie processes on your system they can get to be a problem. The good news is, zombie processes are eventually cleaned up by init(1) after their parent exits. So unless init itself created the zombie, it should be possible to get rid of them without rebooting the system. ps j process_id will help you to identify the parent process and deal with it appropriately. Miquel van Smoorenburg (author and maintainer of the sysvinit package), and lots of other people can probably give you a more technical explanation. BTW, has anyone else noticed that the manpage for ps(1) is uglier than sin? Whose idea of nroff formatting is that? -- G. Branden Robinson | Reality is what refuses to go away when Debian GNU/Linux | I stop believing in it. [EMAIL PROTECTED] | -- Philip K. Dick cartoon.ecn.purdue.edu/~branden/ | pgpfLDRxVNZoH.pgp Description: PGP signature
AMD K5, Netscape, netstat zombies
I got some problem running Netscape 3.04 after I recompiled the kernel. Simply Netscape hangs waiting for a netstat process which becomes zombie. Searching on the net I found this message that was the answer: From Lev Babiev [EMAIL PROTECTED] I have K5-100, and when I compiled kernel for Pentium or Ppro I go some really nasty problems. Netscape would spawn zombie tasks (netstat) and I couldn't even recompile kernel - GCC dumped core. Once I recompiled the kernel for 386 everything works fine. Tried this with 2.0.30 and 2.0.32 So I recompiled for 386 and the problem is solved. Neither 486 is working. Does someone have traced more extensively this problem? Are other programs affected besides Netscape? Is it only a K5-100 CPU problem? Are newer kernels affected too? For the statistics my system is - AMD K5-100 - Debian 1.3.1.r6 with custom kernel 2.0.30 - Netscape 3.04 (the only program which seems to be affected, but I do not tested extensively). To solve the problem I changed only the CPU option in kernel config. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Problem with Netscape making zombies!
Hello Debian Users List!, I seem to be having problems with Netscape 3.01 spawning zombie 'netstat' processes, and thus hanging. I was wondering if anybody knows a fix for this. The only cause I can think of for this is that the Netscape coders forgot to do a 'wait' in the parent process. If thats the case, then there's nothing I can do. However, I don't recall this problem ever occuring before with other distributions. So perhaps it's something else besides sloppy coding? And also, I can sometimes get netscape to start. So this sort of alludes to the idea that it's not Netscape's fault but something else. Thanks in advance for any help on this! == Arcadio Alivio Sincero, Jr. a.k.a. The Tick Undergraduate Computer Science Major/Linux Enthusiast/Competitive Bodybuilder email: [EMAIL PROTECTED] WWW:http://www.coming.to.a.web.site.near.you.com Come meet me on quake.linpeople.org for Quake or irc.linpeople.org for IRC!
Re: Problem with Netscape making zombies!
Tick == The Tick [EMAIL PROTECTED] writes:
Tick Hello Debian Users List!, I seem to be having problems with
Tick Netscape 3.01 spawning zombie 'netstat' processes, and thus
Tick hanging. I was wondering if anybody knows a fix for this.
Tick The only cause I can think of for this is that the Netscape
Tick coders forgot to do a 'wait' in the parent process. If
Tick thats the case, then there's nothing I can do.
Tick However, I don't recall this problem ever occuring
Tick before with other distributions. So perhaps it's something
Tick else besides sloppy coding? And also, I can sometimes get
Tick netscape to start. So this sort of alludes to the idea that
Tick it's not Netscape's fault but something else.
I've seen this too. I've found that if I run netscape from an xterm
that is started to NOT be a login shell, ('xterm +ls ') it works, but
if it is one, then netscape hangs with a zombie netstat, after it runs
some MIME tests
It won't start from my TkDesk toolbar, or from an fvwm2 menu. It will
start from ~/.xsession, the same one that starts the fvwm2... It does
the same thing regardless of whether it's been installed with the
Debian installer. I've watched it with tkps, and it runs a series of
programs from /var/lib/mime/tests, and then finally hangs with the
zombie netstat.
It may be environment dependant; I have not isolated the cause yet...
It seems to depend on where I start netscape from.
The /var/lib/mime/tests/* scripts are not the cause; none of them call
netstat. Hmmm. I'm stumped.
Karl M. Hegbloom [EMAIL PROTECTED]
http://www.inetarena.com/~karlheg
Portland, OR USA
Debian GNU 1.2 Linux 2.0.29t
You tell me and we'll both know.
Re: Problem with Netscape making zombies!
I had a line in my ~/.bash_profile like this: export PATH=.:~/programs/bin:$PATH:/sbin:/usr/sbin:/usr/local/sbin ... hashing it out fixed the netscape problem. It also runs from the fvwm2 menu now, since I added: export PATH=/usr/local/bin:/usr/X11R6/bin:/usr/bin:/bin:~/bin ... to my ~/.xsession just before the call to start fvwm2, which is on the last line of my script. So, the question is: Why does that PATH cause this to happen? Karl M. Hegbloom [EMAIL PROTECTED] http://www.inetarena.com/~karlheg Portland, OR USA Debian GNU 1.2 Linux 2.0.29t You tell me and we'll both know.
exmh suddenly spawns zombies
Suddenly exmh seems to be producing zombie processes whenever I try to reply to a message. Of course, I'm not able to make the reply. Specifically, when I click on the Reply button (then on Reply to sender), exmh shows this message: Starting ASYNC exmh-async xterm -e vi ... But exmh doesn't start the xterm. I do see this in the exmh log: Exwin_Toplevel .log 80x20+177+270 After a few minutes, a background wish process is started: /usr/bin/wish -f /usr/bin/exmh-bg exmh /usr/lib/exmh /usr/b (==the line is cut off here) Then this process is zombie-ized after a couple of minutes. Now, exmh's reply button used to start the xterm just fine. I don't know when this odd behaviour started. (I've been gone for a week, but thought I'd used the reply button since I got back last night; am not really sure what happened in the last day to tell the truth.) I can successfully execute 'xterm -e vi' from the command line. Whatever is causing the problem is not specific to one particular (e.g., badly formed) message; I've tried and failed to reply to many messages. The list of possibly relevant packages is attached below. Obviously, any hints would be very much appreciated. Susan Kleinmann == ii exmh1.6.9-2An X user interface for MH mail. ii expect 5.19.0-1 The expect/expectk programs and libraries. ii nvi 1.34-134.4BSD re-implementation of vi. ii tcl74 7.4p3-4The Tool Command Language (TCL) v7.4 - Run-T ii tcl74-dev 7.4p3-4The Tool Command Language (TCL) v7.4 - Devel ii tcl75 7.5p1-1The Tool Command Language (TCL) v7.5 - Run-T ii tclX7.4a-p2-1 Extended Tcl (TclX). ii tk404.0p3-3The Tk toolkit for TCL and X11 v4.0 - Run-Ti ii tk40-dev4.0p3-3The Tk toolkit for TCL and X11 v4.0 - Develo ii tk414.1-1 The Tk toolkit for TCL and X11 v4.1 - Run-Ti ii tkdiff 1.0b9-3A graphical diff utility. == -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
runq zombies
My system's been running for about a week. I've started to notice lots of
runq zombies (from smail, I guess):
FLAGS UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND
100040 0 10843 1 0 0 106848 11543d S ? 0:00 (runq)
100040 0 11188 1 0 0 106848 11543d S ? 0:00 (runq)
100040 0 11768 1 0 0 1068 180 11543d S ? 0:00 (runq)
100300 0 10841 10839 0 0 0 0 11510f Z ? 0:00 (runq
zombie)
100040 0 10844 10843 0 0 118452 110334 S ? 0:00 (runq)
100300 0 11186 11184 0 0 0 0 11510f Z ? 0:00 (runq
zombie)
100140 0 11734 11188 0 0 1180 288 110334 S ? 0:00 runq
100300 0 11766 11764 0 0 0 0 11510f Z ? 0:00 (runq
zombie)
100040 0 11770 11768 0 0 1180 288 110334 S ? 0:00 runq
I was able to get rid of killing the zombies by killing runq processes
that were their parent(?) processes. Anyone else seen lots of runq
zombies?
--
#!/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj -RSA-3-lines-PERL-
$/=unpack('H*',$_);$_=`echo 16dio\U$kSK$/SM$n\EsN0p[lN*1# Joey Hess
lK[d2%Sa2/d0$^Ixp|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) # [EMAIL PROTECTED]
How appropriate, you fight like a cow. - - Guybrush Threepwood
