Jordan Brown (Sun) writes: > I know you tried to steer us away from the "restart" question, but I > think that remains relevant here.
I'm gonna keep on doing that, because the original problem that we were discussing (before this thread veered out of control) would have been NO DIFFERENT if SMF had done no restart at all. It was the sending of the uncaught (and unexpected) signal to the parent that was the issue, not any restart. > In either event, I don't think the goal is to assign blame for the failure. The goal of sending a termination signal to some subset of all of the processes on the signal is to impute "blame." Those processes are the ones "damaged" by the failure and that are sharing fate. It's the fact that this is a _new_ behavior and that it's really not well-understood that's at issue. > > Still, even in a development environment, I don't want ifconfig(1M) > > (or its invoker) to take a signal if dhcpagent or in.mpathd dies, or > > if dhcpagent's event hook script (from the user) drops core. In those > > cases, that'll happen today, and it's not right. > > I'm not so sure. If those things fail, I *want* the issue raised. In > my more draconian moments, I want it raised so loudly that it cannot be > ignored, so that it _must_ be addressed. (Plus, in a development > environment, doesn't your "all in the same playground" comment apply?) I want _an_ issue raised when those problems occur, regardless of environment. However, it's not the _fault_ of ifconfig or its invoker if anything goes wrong with these other processes. That's the point I'm trying -- very hard -- to get across. -- 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
