On Sunday, Apr 6, 2003, at 16:30 US/Pacific, Paul Ripke wrote: On Sunday, Apr 6, 2003, at 12:01 Australia/Sydney, Jean-Edouard BABIN wrote: Justin Walker icrit: [snip] Odd. I have one too: ksh$ ps alx | grep Z UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 509 0 0 0 0 0 0 - Z con- 0:00.00 (scselect) Just a hunch, but I'd guess that the real PPID isn't zero. I'd say ps is reading a struct which has been nulled, and there's another copy of the real PPID elsewhere. UTSL... This was mentioned earlier in this thread. When a process is inherited by 'init' (PID 1), which happens when the parent process exits before the child, the child's "parent PID" entry in its proc table is cleared (init really isn't its parent; the child is just "attached" to init so that it can be 'reaped'). This is the last step in cleaning up after a process exit, and is something that a process can't do for itself (unlike that cute box that, when you turn it on, has a hand that comes out, turns the switch off, and retreats back into the box). This general behavior has been around for a while, I believe [Unix lore]. I haven't checked other source to be sure. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------* _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.