John Forte wrote: > David Powell wrote: >> > A follow on question is do I need to call scf_pg_create on the >> > instance? It appears that property groups and properties are not >> > really inherited, they're somehow inherited for list purposes via >> > svcprop (and I assume the library get interfaces but I haven't tried >> > that yet) such that I would need to create the property group on the >> > instance in addition to the parent service if properties on that >> > instance only were expected to be modifiable by the admin. >> >> You do not need to call scf_pg_create on the instance. You do need >> to refresh the instance after making the change to the service for it >> to take effect, though. We require this so that if you were to make >> several changes to the service or instance, you don't run the risk of >> the instance seeing an incomplete or inconsistent configuration. > > Okay. So does that imply that once I issue a refresh on the service, > either via libscf or svcadm, I should see the property group(s) I > created on the parent service using listpg?
No. listpg on an instance only shows those property groups and properties which are attached to that specific instance; i.e. it shows you the underlying structure of the configuration. You only see the composition of the instance and the service when you read that instance's configuration through svcprop(1) or scf_instance_get_pg_composed(3SCF). > As you indicated, I do > indeed see the property group I created via 'svcprop <service-name>' > after issuing refresh and using 'svcprop -c <service-name>' before the > refresh , but after the refresh I still cannot modify the property > group/property as the error message returned indicates the property > group does not exist on the instance nor does listpg show it. Sorry if > I'm still missing something obvious here. When you add the property group to the service, you are creating something whose existence and settings are inherited by all that service's instances. You can then change that property and all instances (when refreshed) will pick up the new property value. If you want to assign per-instance values to a property, you need to create the property at the instance level. You might be thinking of the service and its properties as being a pattern for an instance; that isn't the case. The service is a concrete entity that is shared among its instances. (That said, investigating ways to simplify making per-instance customizations of commonly-structured configuration is on our list of things to do.) > And if it matters at all, this particular service does not have a > refresh method defined in the manifest as it cannot effectively support > refresh but I am assuming that there is some default behavior defined > for start, stop and refresh when a method is not declared. Maybe this is > part of my problem as well. A refresh of the service does two things: it creates a new "running" snapshot from the current property values and then can perform some restarter-specific action. In the case of the default restarter (svc.startd), it will execute the "refresh" method, if it exists. Not having a refresh method shouldn't affect how properties are updated. Dave
