> One final comment here: although the above mechanism > could be used for ipmievd > and definitely is needed for a few other things, it's > also worth noting that > ipmievd's needs could be expressed in a different > way: namely as a device > dependency. That is, another potential missing > mechanism in SMF which we had > discussed long ago was a dependency on a /dev path, > which is really what > ipmievd is trying to express. This is even more > conducive to the kind of > reporting I mention above, because svcs -x would then > be able to produce > a message of the form "disabled because /dev/bmc > isn't present on your system" > > So while the ipmievd team can work around the absence > of either feature now > by doing (2), it would be nice to see one or both of > these capabilities added.
Very true. One problem with simply disabling the service is that it's difficult to tell at a glance that this was dynamically determined by the method and was not an administrative action. An administrator may misunderstand that the service requires the device and thinks that it needs to be running. Several rounds of 'svcadm enable <service>' that apparently do nothing can cause some serious head scratching. The log file helps, but it's not the first thing I think of when the service seems to be sitting there quietly. :-) -- Darren This message posted from opensolaris.org
