SMF snapshots, or why didn't my property change show up in svcprop?
By user12820842 on Jul 25, 2008
One area of SMF that is a bit confusing is the whole notion of snapshots, refresh and how property updates occur. I find this a bit tricky myself, so if there's mistakes below, I'll happily correct them.
A snapshot is essentially a read-only picture of a set of property groups associated with an instance and its parent service. The most important snapshot is the 'running' snapshot, as it is the place applications (including svcprop) and service methods should read their configuration from. Why is this?
My understanding is that the snapshot model is there (in part at least) to allow atomic commit of multiple changes. This is particularly important for services that consume such configuration information. Imagine I want to change two properties in an inetd service. I'd like to change a tcp service from a wait-type (only handling one connection at a time) to a nowait-type service with a specific maximum connection rate. I need to change two properties - the 'wait' property, and the 'max_con_rate' property, since nonzero values for the latter only makes sense for nowait services. The snapshot model allows me to change each individually with svccfg, then refresh. The refresh action updates the running snapshot to contain a read-only picture of the latest values of my properties (it also runs the refresh method associated with the service instance, if there is one). Then entities consuming these values will see both changes at once as the running snapshot is updated atomically.
Sometimes you'll see the actual service and instance property values referred to as the 'configuration' or 'editing' snapshot, but that's not quite accurate, since as we saw above, snapshots are read-only and we make our changes to the actual configuration values, not a frozen picture of them.
If you select an instance using svccfg, you can see there's a bunch of snapshots in addition to 'running':
# svccfg -s nwam svc:/network/physical:nwam> listsnap initial last-import previous running start svc:/network/physical:nwam>
Here we see another aspect of snapshots. svccfg(1M) allows us to revert back to earlier snapshots. The names of the various snapshots are pretty self-explanatory. The idea is, if I mess up my configuration, I just need to revert to the initial snapshot, or the one associated with last manifest import, etc.
You'll note something that seems weird - 'refresh' can be carried out both by svcadm and svccfg. Why is this? Well as we saw earlier, refresh has a configuration component - update the running snapshot - and an action component - run the refresh method. Configuration actions belong in svccfg, and actions in svcadm, so it makes sense to have refresh in both. Also, it's possible you may need to update the running snapshot in a SMF repository that's not currently running - maybe you made a configuration change that makes the system unbootable, and it's in the running snapshot, so you can't fix it with svccfg. Having refresh in svccfg makes such problems fixable, since it can operate on an inactive SMF repository. More on this another time.
So finally, why didn't my svccfg property change show up in svcprop? Because svcprop reads from the running snapshot, and until refresh is run, the changes haven't hit that snapshot yet.