Quoth Michael Shapiro on Sat, Nov 25, 2006 at 01:16:23PM -0800: > > Quoth Cathy Thomas on Fri, Nov 17, 2006 at 12:58:50PM -0800: > > > My service (ipmievd) will not run if the local host does not have > > > a BMC device available. ipmievd itself will return a 1 and give an > > > error message that "no BMC is available". > > ... > > > > You currently have three options: > > > > 1. The start method detects that the BMC is unavailable (either by > > itself or through the daemon) and reports a fatal error to SMF. > > The service ends up in the maintenance state. > > > > 2. The start method detects that the BMC is unavailable and disables > > the service. The service ends up in the disabled state. > > > > 3. Even though the daemon detects that there is no BMC device, it > > stays running, presumably doing nothing. The start method reports > > success and the sevice enters and stays "online". ... > In terms of the daemon, I think the only sensible behavior is (2). (1) doesn't > make sense because there's nothing broken -- i.e. nothing for someone to > repair. (3) might make sense for some daemons, but not this one, because > fundamentally if there is no BMC it means the platform has none -- this isn't > a DR'able resource, and thus you're just wasting CPU + memory. Plus ipmievd > being a bunch of open source, it likely just fails or exits if BMC is missing.
I think that to most users, services disabling themselves would be confusing. I think that once a user encountered such a service, he would be more likely to think that he misspelled the FMRI or that svcadm is broken than to run svcs -x on it or guess that the service is disabling itself. And if he did learn what was going on, I think it's likely that it would plant a seed of mistrust: "If a service can disable itself when I try to enable it, what's keeping any service from disabling itself at any time? Or any other software from disabling any service? Do I have to keep a list of the services that I want enabled and check them each minute?" Certainly, I don't think it's appropriate for self-disablement to become a best-practice without svcs -x being able to explain what happened, svcadm enable -s failing in that case, and a campaign to change the documentation to explain that "disabled" means "not running either because you didn't want it to or because the system didn't think it was appropriate -- use svcs -x to distinguish". I suppose "svcs" differentiating temporarily-disabled services from persistently-disabled services in the default listing would help, too. But I'd rather us not require users to have to keep this in mind whenever they enable services and instead have the service go into "maintenance", for which we train people to run svcs -x. Your argument that "(1) doesn't make sense because there's nothing broken" is wrong -- the administrator asked for a service which the hardware cannot provide. That sounds broken to me. Now if we did advise service authors to put their service into maintenance if the hardware can't support the service, there is the question of what to do when the hardware can change frequently -- apparently like Xen. The administrator might want a service to be "enabled only when the hardware is right". Putting the service in maintenance otherwise wouldn't really be appropriate. A solution to this isn't clear to me. On the one hand, Enhanced SMF Profiles would allow the desired behavior at platform granularity, since it will allow the system to reselect the appropriate platform profile on each boot. But it seems that developers want finer granularity -- down to the device, as you suggested with /dev dependencies. That's appealing except that it would result in those services being in "offline", which we usually consider a problematic state. We could allow the developer to flag the dependency as disable-if-unsatisfied, as John suggested, but I don't know, seems weird to me. David
