"Jordan Brown (Sun)" wrote: > > James Carlson wrote: > > If something goes wrong in libc, my process address space may be > > trashed. I have no way of knowing how bad the problem is. The best > > thing I can do is to exit abruptly, so that I don't hurt anyone else > > by spewing corrupted data into the rest of the system. > > Yeah, mostly. I agree that the process boundaries help a lot to contain > the fault. However, I'd say that often the reason that the underlying > component failed was that it was fed bad data (which is usually how the > libc routine gets a NULL to play with), and that says bad things about > the higher-level component. (I'll admit that that kind of thing tends > to cause ordinary failures, rather than core dumps, and so the policies > here wouldn't detect it.) > > > I can't reach into other address spaces, so those guys are still ok. > > (Yes, there's an interesting fate-sharing issue with shared memory, > > and having a mutual-core-dump pact among processes attached to a > > shared memory segment sounds like a cool idea, but we're not talking > > about anything like that here.) > > There's also shared files, databases, output streams, and so on. They > aren't *totally* independent. A sed dying, ignored by its parent shell, > can lead to damaged data being written into a file, and so on.
How does SMF detect that a child process failed ? Note that any exit code from 0 ... 255 is _valid_ for shell scripts and applications and killing whole services just because a child process returned a non-zero exit code may not be a good idea (I hope it's not implemented this way). The same applies to SIGTERM and other signals - shell scripts sometimes employ signals for communication and that includes even stuff like SIGTERM and SIGHUP and the child processes may not be cleaned-up immediately (for example if there are other events to process the reaping of dead children may need some time). ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
