🚀 go-pugleaf

In article <1dmp94INNppe@uwm.edu> xepo@csd4.csd.uwm.edu (Scott R Violet)  
writes:
=>
=>I am not sure if this fits properly in this group, but I have noticed
=>with a program that I am writing for the NeXT, and was figuring that
=>maybe it is something I am doing that I should be doing.  What
=>happens is that I run my program and after a while I ^C it to stop.
=>After that if I do a 'ps -aux' I notice that there is a extra -1 task
=>running under root.  What could cause this problem?  And, I found out
=>that it isn't a good idea to try an kill them...
=>-- 
=>
=>		-Scott Violet (xepo@csd4.csd.uwm.edu)

A process with a PID of -1 (also stated as <mnach-task>) is really a zombied  
process.  A zombie doesn't not really cause any harm to the system, except  
that it consumes 1 slot in the process table, of which there is a finite  
number of slots.  When you run out of process slots, you will crash.

It seems that one of the major creators of zombies is NeXT's Terminal.app.   
Generally whenever you close a terminal.app window, a zombie will be created.

Btw, the zombies can not be "killed" (even will kill -9).  Don't even bother  
to attempt it.  But if you do, be prepared to reboot from a panic :-)


--
Paul S. Sears                *  sears@uh.edu (NeXT Mail OK)
The University of Houston    *  suggestions@tree.egr.uh.edu (NeXT
Engineering Computing Center *  comments, complaints, questions)
NeXT System Administration   *  DoD#1967 '83 NightHawk 650SC 
          >>> SSI Diving Certification #755020059 <<<
"Programming is like sex: One mistake and you support it a lifetime."

In article <1992Nov10.152955.21859@menudo.uh.edu>, sears@tree.egr.uh.edu writes...
#A process with a PID of -1 (also stated as <mnach-task>) is really a zombied  
#process.  A zombie doesn't not really cause any harm to the system, except  
#that it consumes 1 slot in the process table, of which there is a finite  
#number of slots.  When you run out of process slots, you will crash.
# 
#It seems that one of the major creators of zombies is NeXT's Terminal.app.   
#Generally whenever you close a terminal.app window, a zombie will be created.
# 
#Btw, the zombies can not be "killed" (even will kill -9).  Don't even bother  
#to attempt it.  But if you do, be prepared to reboot from a panic :-)

Interesting.  So why is it that Project Builder creates a NEW terminal.app
window EVERY time you click on "debug"?  (I do that a lot.)

Do they disappear when you log out?  Or, do you have to reboot?

      Dick Silbar (NeXTMail:silbar@whistler.lanl.gov)

In article <1992Nov10.152955.21859@menudo.uh.edu> sears@tree.egr.uh.edu writes:
>A process with a PID of -1 (also stated as <mnach-task>) is really a zombied  
>process.  A zombie doesn't not really cause any harm to the system, except  
>that it consumes 1 slot in the process table, of which there is a finite  
>number of slots.  When you run out of process slots, you will crash.
>
>It seems that one of the major creators of zombies is NeXT's Terminal.app.   
>Generally whenever you close a terminal.app window, a zombie will be created.
>
>Btw, the zombies can not be "killed" (even will kill -9).  Don't even bother  
>to attempt it.  But if you do, be prepared to reboot from a panic :-)

While a zombie'd process may appear as a <mach-task>, all <mach-task>'s
are not zombie'd processes.  <mach-task>'s are what they say they are,
Mach tasks. Most of them (my machine typically has 5 ) are kernel tasks
such as the sound driver and other drivers.  They aren't really Unix
processes, just bare bones Mach tasks.

A kernel loaded server exists as one of these <mach-task>'s and you can
create user level ones with task_create().  They do have a purpose.

Unless an inordinate amount of them are being generated they belong there
just as any of the other daemons and processes...

la la la,
-- 
::   Christopher Lloyd  ::  a74k110@titan.ucc.umass.edu  ::  Yrrid, Inc.    ::

In article <1992Nov10.152955.21859@menudo.uh.edu> sears@tree.egr.uh.edu writes:
>In article <1dmp94INNppe@uwm.edu> xepo@csd4.csd.uwm.edu (Scott R Violet)  
>writes:
[stuff deleted]
>=>After that if I do a 'ps -aux' I notice that there is a extra -1 task
>=>running under root.  What could cause this problem?  And, I found out
>=>that it isn't a good idea to try an kill them...
>=>		-Scott Violet (xepo@csd4.csd.uwm.edu)
>
>A process with a PID of -1 (also stated as <mnach-task>) is really a zombied  
>process.  A zombie doesn't not really cause any harm to the system, except  
>that it consumes 1 slot in the process table, of which there is a finite  
>number of slots.  When you run out of process slots, you will crash.

Yes, there is a finite amount of them, but it's only limited by the
memory you have (it's not an arbitraty limit such as '128 processes').

>Btw, the zombies can not be "killed" (even will kill -9).  Don't even bother  
>to attempt it.  But if you do, be prepared to reboot from a panic :-)

If you try to kill processes with negative PIDs, you won't kill them,
but you will kill the process group with the corresponding positive
ID. As a speciale case, -1 refers to every process owned by you (root:
every process), except the process sending that signal (but, of course
including its parent processes, such as Stuart or Terminal).
Therefore, you won't get the expected result when killing -1.

-Marcel

To avoid zombies, a UNIX process doing a fork (a parent process)
must reap it's child(ren).  This is done by some varient of the
wait(2) system call, and it may be helpful to install a SIGCHLD
handler.  The man pages seem to imply that wait() is an optional
feature, but failure to call it will result in a zombie.

It sounds like Terminal is not doing this properly.  The Subprocess
example does not seem to do this, either.

Most UNIXes I'm familiar with report zombies as <defunct>, but
Mach apparently doesn't, if what's been reported here is correct.
Also, on other UNIXes, killing them (from root) is no problem.

-- 
Ray Spalding, Office of Information Technology
Georgia Institute of Technology, Atlanta Georgia, 30332-0715
Internet: ray.spalding@oit.gatech.edu (NeXT Mail accepted)

[ Distribution usa as on Ray's article does not work - besides why do ]
[ you want people outside usa not to get your articles?               ]


cc100aa@xray.gatech.edu (Ray Spalding) writes:
>To avoid zombies, a UNIX process doing a fork (a parent process)
>must reap it's child(ren).  This is done by some varient of the
>wait(2) system call, and it may be helpful to install a SIGCHLD
>handler.  The man pages seem to imply that wait() is an optional
>feature, but failure to call it will result in a zombie.

I think this description isn't quite correct, but I may be wrong: You
only get a zombie, when the parent exits without wait(2)ing for its
childs. When you can be shure, that the children die before the
parent, you don't need to wait(2), but you may for other reasons.
-- 
Heiko W.Rupp  Gerwigstr.5  7500 Kh'e 1  hwr@pilhuhn.ka.sub.org  +49 721 693642
When the weight of the paperwork equals the weight of the plane, the
plane will fly.
		-- Donald Douglas

In article <74594@hydra.gatech.EDU> cc100aa@xray.gatech.edu (Ray Spalding) writes:
>To avoid zombies, a UNIX process doing a fork (a parent process)
>must reap it's child(ren).  This is done by some varient of the
>wait(2) system call, and it may be helpful to install a SIGCHLD
>handler.  The man pages seem to imply that wait() is an optional
>feature, but failure to call it will result in a zombie.
>
>It sounds like Terminal is not doing this properly.  The Subprocess
>example does not seem to do this, either.

    If the parent process exits any unreaped zombies are supposed to go
    away.  Therefore, logging out *should* fix the problem.

    If it doesn't, it's a bug.  Another problem that I've found... you
    can't kill a process that is blocked in device-open (e.g. blocked on a
    dialup tty).  That is definitely a bug, when you kill a process (kill
    -9 pid) it's supposed to die, period.

					-Matt

>Most UNIXes I'm familiar with report zombies as <defunct>, but
>Mach apparently doesn't, if what's been reported here is correct.
>Also, on other UNIXes, killing them (from root) is no problem.
>
>--
>Ray Spalding, Office of Information Technology
>Georgia Institute of Technology, Atlanta Georgia, 30332-0715
>Internet: ray.spalding@oit.gatech.edu (NeXT Mail accepted)

--

    Matthew Dillon		dillon@Overload.Berkeley.CA.US
    1005 Apollo Way		uunet.uu.net!overload!dillon
    Incline Village, NV. 89451	ham: KC6LVW (no mail drop)
    USA 			Sandel-Avery Engineering (702)831-8000