It seems to me tha the problem is there are two states and three cases: 1) administrative disablement because of administrator preference 2) "maintenance" because of a correctable error (s/w or h/w config, dependency problems) 3) "can't run" because a required h/w or condition is not present (not right platform, absence of device, absence of particular bus technology, etc.)
1 maps to 'disabled', 2 maps to 'maintenance', but 3 really is a different case. There's no purely-administrative action that can resolve it like most 'maintenance' states, but it's not an arbitrary rescindable policy decision either. David Bustos wrote: > 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
