http://defect.opensolaris.org/bz/show_bug.cgi?id=10805
--- Comment #5 from Renee Danson Sommerfeld <renee.danson at sun.com> 2009-08-20 17:26:40 UTC --- (In reply to comment #4) > That seems reasonable, but the problem is the order in which we carry out > operations such as commit and destroy is: > > 1) update the configuration in netcfgd > 2) update the state in nwamd > > This order is needed for commit-type events since nwamd re-reads the > configuration for most operations (e.g. commit triggering a refresh). If we > accept that this ordering is necessary, we are left in the awkward situation > that the object is effectively already gone by the time we run the stop > script, > so there's nothing to put into maintenance. > > It may make sense to reverse this order for destroy events, but I'm worried > that'll make life quite complicated. I'd also be worried that it would be > possible to make undestroyable objects if the script or service didn't exist. Ah, I spaced on the "destroy" part. If the object's been destroyed, it's hard to have state associated with it, huh! I guess in that case the best we can do is a log message (maybe higher than debug, so it shows up in /var/adm/messages for the default syslog settings) noting that the stop method failed. Sorry for the confusion... -- Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
