Changing an SMF-managed service's configuration with svccfg instead of editing its config file

Goal

Change the persistent configuration of an SMF-managed service (for example the DNS resolver) the supported way, so the change survives a service refresh and is not silently overwritten.

Prerequisites

Rights to modify the service configuration repository for the target service (root role or an assigned profile); the service's FMRI and the property group holding the setting to change, found with listprop before writing anything.

Steps

1. Read current values before changing anything: svccfg -s <fmri> listprop lists every property group and property with its type; narrow to one group with svccfg -s <fmri> listprop <pg>.
2. Change a property non-interactively: svccfg -s network/dns/client setprop config/nameserver = net_address: '(10.0.0.1 10.0.0.2)' — on the shell command line the parenthesised list must be quoted, or the shell rejects it. The same subcommand works unquoted inside an interactive svccfg -s <fmri> session at its prompt.
3. Apply the change to the running instance: svcadm refresh <fmri>. setprop only edits the repository; the running service keeps using its running snapshot, and only a refresh copies the new values into it. svcadm restart alone does not update that snapshot — for services that read configuration only at start, refresh first, then restart.
4. Validate the change took effect: svccfg -s <fmri> listprop <pg> shows the repository values, while svcprop -p <pg> <fmri> shows what the running instance sees (its running snapshot). For a DNS client, the documented procedure also sets config/search, sets config/host = astring: "files dns" on svc:/system/name-service/switch, refreshes both instances, and enables dns/client and name-service/switch if they are disabled.
5. For a brand-new property with no existing default, create the property group first with svccfg -s <fmri> addpg <pg> <pgtype> before running setprop inside it.

Expected result

listprop shows the new value, the refreshed instance behaves accordingly (a DNS client rereads its configuration as regenerated from the SMF properties), and the change survives a reboot because the repository, not a flat file, is authoritative.

Limits and test basis

Never hand-edit a config file that SMF generates from service properties: for network/dns/client, Solaris regenerates /etc/resolv.conf from the SMF properties, so a manual edit is overwritten the next time the service refreshes. Not every SMF service works this way (many still read their own file), so check the service's documentation before assuming either. To undo, save the output of listprop <pg> before a risky change and setprop back to the old value, or drop administrative customizations with svccfg -s <fmri> delcust <pattern> (run listcust with the same arguments first to see what would be removed); either way, follow with svcadm refresh. This applies to Oracle Solaris 11.4; illumos distributions inherit the same svccfg repository model.