Tony Nguyen writes:
> David Finberg wrote:
> > I'm seeing some surprising (to me) behavior on scf_simple_prop_get,
> > and I was looking for an explanation.
> >
> > say I have some service, and I do
> > prop = scf_simple_prop_get(NULL, NULL, "config", "testval");
> > if (prop) {
> > if ((val = scf_simple_prop_next_boolean(prop)) != NULL)
> >
> > inside my service's executable. What happens if svccfg is used to
> > change config/testval, the change is not committed via a refresh, but
> > my service dies and restarts.
> >
> Hi Dave,
>
> The new property value not committed via a refresh is stored in the
> repository as an 'editing' property. The next svcadm refresh will use
> the editing property values to update the running snapshot.
>
> > What I expected was that the old, i.e. the running (svcprop -s running
> > -p config/testval) state would be returned. But instead, the current
> > state of the repository is returned. Is this the right behavior? And
> > is there some simple explanation of why I want that in this case,
> > since I guess my intuition is way off here.
> It's the expected behavior though a bit confusing. If you always want to
> read from the running state(snapshot), use the
> scf_instance_get_pg_composed interface with a running snapshot argument.
> See enable_fmri_rec in cmd/svc/svcadm/svcadm.c.
It's actually a *serious* bug, but one that's near impossible to fix
given that some existing consumers are mistakenly relying on the behaviour.
Sigh. Sorry for not catching the problem before S10 shipped, when
we had a chance to do something about it.
The solution we'll look to is to write an actually easier to use
simple interface that does the right thing from the get go. (As
mws and others have requested.)
liane
