Re: !!!HELP!!! Zombies claim Sparc 2 running Solaris 2.5

Bert Lee Medley wrote:
>
> We have a continuously running process, written in C, that connects to an
> ORACLE database, performs a set of tasks, disconnects, and then sleeps a
> while using the Solaris C sleep function. No special accommodations are
> made for sleep. The machine is filling up with <defunct> processes as a
> result of this code!
>
> Doea anyone have any ideas why the <defunct> processes are created and how
> to prevent them from birthing?
>

They may be child processes which have been fork()'ed, have executed, have exit()'ed, but the parent process has not wait()'ed on them yet. Solaris 1's ps(1) command has a -j flag to print the parent process id's,
and this will tell you which process owns these zombies. Sol2 has a similiar option, I'm sure, but you'll have to check the man page yourself.

More than likely, they were once useful processes, so you don't want to keep them from "birthing"; rather, you want to ensure that they die properly. If you use dbx or gdb as a debugger, you can stop in fork() to see where they're being born. Then you can hopefully figure out the properly cleanup function to call to get rid of them. For example, the fork()'s may be happening in a dbopen() call to your database; then, you might investigate whether or not you're successfully calling the appropriate dbclose() call when you're done.

If you're doing system() calls, you need to let the system handle the SIGCHLD signals; this is the default behavior, but you may have instantiated your own signal handler along the way...? If so, call signal() before your system() (to use SIG_DFL), then after your system(), call signal() again, reestablishing your own handler.

-- 
		-rb
NOTE: Send replies to: rbrown_at_era.com	(no ads, and no spams, please)
    Before sending me unsolicited ads, be sure to see:
	http://www.law.cornell.edu/uscode/47/227.html
My opinions may or (more likely) may not reflect those of my employer.