Turns out it was fetchmail. Restarting it cleaned it all up. Thanks
Bob Miller ([EMAIL PROTECTED]) wrote*: > >Bob Crandell wrote: > >> Hi, >> I have a server with a growing number of these: >> 20344 ? Z 0:00 [sh <defunct>] >> 20354 ? Z 0:00 [sh <defunct>] >> 20355 ? Z 0:00 [sh <defunct>] >> 20363 ? Z 0:00 [sh <defunct>] >> >> How do I get rid if them? How do I find out what's causing them? > >Use "ps fax" to see who their parent process is. (You can also look >at the PPID field with "ps lax", but "ps fax" is easier to read.) > >The only way to get rid of them is to fix or kill the parent. > >What's happening is that those processes are zombies. They've exited, >but their parent(s) haven't waited on them. So the process hangs >around in zombie state, with just enough information for the parent to >extract their status (exit status, which signal killed them, whether >there was a core dump, and what resources they consumed). > >If a parent exits before the child, the child becomes an orphan and is >given process 1 (/sbin/init) as its parent. Init always waits on its >children. > >If you're writing the parent, and you don't want to bother waiting for >the child, you can disinherit it by making it your grandchild. In sh, >you'd replace this: > > long_running_process & > >with this: > > (long_running_process &) > >The parentheses create a subprocess, which only exists long >enough to create the subsubprocess (grandchild). > > > -- Bob Crandell Assured Computing When you need to be sure. Cell 541-914-3985 FAX 240-371-7237 [EMAIL PROTECTED] www.assuredcomp.com Eugene, Or. 97402
