[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensolaris-smf-discuss
Subject:    Re: [smf-discuss] general/enabled is required for general_ovr/enabled?
From:       Tony Nguyen <Truong.Q.Nguyen () Sun ! COM>
Date:       2007-03-21 23:25:18
Message-ID: 4601CD5A.3070207 () sun ! com
[Download RAW message or body]

Liane Praza wrote:
> Tony Nguyen writes:
>   
>> A transient enabling creates general_ovr/enabled property and sets the 
>> state to 'true (temporary)'. However, if the general/enabled property is 
>> missing, the instance can't come online and stays at disabled state. 
>> Adding the general/enabled property will make the instance become 
>> online. So it looks like general_ovr/enabled requires the existence of 
>> general/enabled.
>>
>> Two questions.
>> Why does general/enabled property need to exist? Or I'm missing 
>> something here.
>>     
>
> Currently, svc.startd takes the existance of a general property group
> on an instance as a key to take notice of the instance and start
> doing something about it.
>
> There are 2 main reasons for this:
> 1) startd doesn't do anything useful with a service that isn't enabled.
>
> 2) It was a quickly-implementable way to ensure that startd didn't
>    notice a service until we finished importing it.  That is, during
>    svccfg import we set the general/enabled property *last* so that
>    startd doesn't try to start up a service that's half imported.
>
>    I'm not proud of that particular bit of implementation, but it
>    solved the problem at hand when we were under quite a bit of time
>    pressure.
>
> The comments with libscf_get_basic_instance_data() and
> dgraph_update_general() in the startd code give a clue to the
> behaviour, but we should be more explicit in the header comment of
> graph.c.
>
> (svccfg seems silent about this behaviour in its comments, though the
> SCI_GENERALLAST flag is the setting which controls creating general
> last.)
>
> I'm also not the biggest fan of the general_ovr implementation, and
> hope that someday we will have temporary overrides of properties that
> aren't required to use an alternate namespace defined only by convention.
>
>   
This make a lot more sense. I'll look closer into this.
>> We can create general_ovr/enabled if it doesn't exist in 
>> set_inst_enabled_flags, can't we do the same for general/enabled if 
>> doesn't already exist when need to enable general_ovr/enabled?
>>     
>
> I infer from your statement that
> smf_[enable|disable]_instance(*, SMF_TEMPORARY) doesn't create both
> general/enabled and general_ovr/enabled (when they don't exist)?  If so,
> sounds like a bug.
>
> Feel free to file and fix. :)
>
>   
In set_inst_enabled, we only check for the existence of property group 
we're enabling(either general or general_ovr) and create that if it 
doesn't exist. We should probably always check for the existence of 
general/enabled property and create it if necessary. I'll file a bug and 
assign myself to it :^)

Thanks,
-tony
_______________________________________________
smf-discuss mailing list
smf-discuss@opensolaris.org
[prev in list] [next in list] [prev in thread] [next in thread]