hmmm... well, i've never heard of that before. parts of it make sense... memory under a zombie couldn't be swapped by the kernel because the process couldn't be accessed. not being able to access memory would definitely create a segfault - either on the part of the zombie or the working process trying to swap memory with the zombie. that could explain how an "rm -rf" could segfault.

however... i definitely remember reading somewhere that zombies don't take up any resources except on the process table - they're more annoying than dangerous.

my best guess would STILL have something to do with running the process under nohup - especially if the processes work fine without running under nohup. i'm actually wondering if it might not be a bug in jvm. maybe they didn't design it to work without being able to recieve the kill signals.

This helps a lot, thank you. I've been told by the server support team that the nohup process, once orphaned by hanging up the terminal, is picked up by 'init', which explains the 'parent=1' issue.

It's tricky to tell whether the app *really* runs fine when not under nohup -- I can't test it for 48 hours to see (since I have to be dialled in to keep the connection open, and the ISDN link times out after extended inactivity). If there *is* an IBM JVM bug with nohup, how else could I run Java? I need to execute a shell script, which sets some env vars and invokes java, and keeps running.

I can (dimly) understand how running out of RAM might cause problems with swap space which cause other apps to fail (e.g. rm -rf and ls) -- but how would this happen if the culprit is a buggy JVM?

Thanks very much indeed for the time you've put into this - I have a very unhappy client, and am rapidly running out of suggestions other than "get a bigger box and see if it improves".