Liane Praza writes:
> Yep. And Dave already went over in the first message of this thread
> how you can opt out of that behaviour as either a service developer or
> an admin.
Right ... though both approaches have some warts to deal with.
> This default is how we can make the entire system more fault tolerant in
> the face of things like uncorrectable memory errors. Remember, in S9 we
Yes, I understand the rationale behind it; it's the unintended
consequences that are of interest to me (at least for this thread).
> But, I'm not really sure what you're trying to accomplish with this
> discussion, Jim. Are you trying to propose that we un-do this default
> which was set in S10 and break programs and service definitions which
> were made based on these defaults?
No, no -- not at all. I'm not sure about others on the thread, but
I'm interested in finding out:
a) what the correct practice really is here; I'm slowly gathering
that contract-awareness is *required* for processes that start up
things for which they're disclaiming direct responsibility.
b) how much additional investigation is required; I suspect that
there are far more of these sorts of cases buried in the source
base than we realize, and that it'll take some time to ferret
them out.
c) whether there are features missing from SMF that should be added;
on that score, I think that on-demand service behavior is a gap.
> I do understand your concerns, but believe that this was one of those
> tradeoff calls. Either we make things behave in a manner least likely
[...]
Yep; that's understood. I'm interested in what to do in order to play
nice. And I'm pretty sure that (as I mentioned to Dave Powell about
sendmail) merely disabling restart on core dump is the wrong answer.
It might be an _expedient_ answer (not having to track down all of the
exposed external process invocations that fall under the "disclaiming"
issue), but I don't think it's actually right, which means there's
more (and Sun-specific) work to be done.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
