Paul Neary writes: > I'm setting up debugging of svc.startd (which works) but I can't get at > the property using svcprop. > > o Use svccfg to set the property > # svccfg > select svc:/system/svc/restarter:default > svc:/system/svc/restarter:default> addpg options application > svc:/system/svc/restarter:default> setprop options/logging = astring: debug > svc:/system/svc/restarter:default> listprop options/logging > options/logging astring debug > svc:/system/svc/restarter:default> quit > > o using -p > # svcprop -p options/logging svc:/system/svc/restarter:default > svcprop: Couldn't find property group `options' for instance > `svc:/system/svc/restarter:default' > > > o When I export the SMF Manifest the options just set are visible in the > xml file. > > What's the explanation for this behavior (not being able to successfully > use the -p option after setting up a property group)? > > -paul
SMF has the concept of a running snapshot for service instances. It is the property values in the running snapshot that the instance uses to control its operation. Also by default, svcprop is going to show you the running snapshot values. Actually, that is a bit of an over simplification, so see the Description section of svcprop(1) for details. When you use svccfg to edit properties the new values are not automatically placed in the running snapshot. The reason for this is that you may need to edit more than one property to accomplish a given task. It would be bad to have the running snapshot be in an inconsistent state with some properties in their edited state and others still to be edited. Once you finished editing the properties, you need to issue the refresh command. On all systems you can do this with "svcadm refresh instance_fmri". At some point refresh was also added as a subcommand to svccfg, but I don't recall exactly when this was done. When you refresh the instance, your edits will be moved into the running snapshot. tom
