puppetlabs/puppet · error · Puppet::Error
Cannot manage legacy services through SMF
Error message
Cannot manage legacy services through SMF
What it means
The SMF provider maps svcs state strings to Puppet symbols; the mapping explicitly refuses 'legacy_run' with 'Cannot manage legacy services through SMF'. A legacy_run state means the service was started through the legacy rc/init mechanism (svcs reports it under the legacy zone/path) and is not an SMF-managed instance, so svcadm cannot control it.
Source
Thrown at lib/puppet/provider/service/smf.rb:227
states = service_states
state = states[:next] || states[:current]
rescue Puppet::ExecutionFailure => e
# TODO (PUP-8957): Should this be set back to INFO ?
debug "Could not get status on service #{name} #{e}"
return :stopped
end
case state
when "online"
:running
when "offline", "disabled", "uninitialized"
:stopped
when "maintenance"
:maintenance
when "degraded"
:degraded
when "legacy_run"
raise Puppet::Error,
"Cannot manage legacy services through SMF"
else
raise Puppet::Error,
"Unmanageable state '#{state}' on service #{name}"
end
end
# Helper that encapsulates the clear + svcadm [enable|disable]
# logic in one place. Makes it easy to test things out and also
# cleans up flush's code.
def maybe_clear_service_then_svcadm(cur_state, subcmd, flags)
# If the cur_state is maint or degraded, then we need to clear the service
# before we enable or disable it.
adm('clear', service_fmri) if [:maintenance, :degraded].include?(cur_state)
adm(subcmd, flags, service_fmri)
end
# The flush method is necessary for the SMF provider because syncing the enable and ensureView on GitHub (pinned to e227c27540)
Solutions
- Check how it runs: svcs -l and ps to confirm the legacy rc-script origin
- Convert the daemon to a real SMF service (write/import a manifest with svccfg import) and manage that FMRI
- Or manage it outside SMF with the init-style provider/commands and stop listing it under smf
- Stop the legacy instance before enabling the SMF one to avoid duplicates
Defensive patterns
Strategy: fallback
Validate before calling
svcs -H -o state "${name}" 2>/dev/null | grep -qx legacy_run \
&& echo "legacy rc service — manage via init commands, not SMF" Prevention
- Convert legacy rc daemons to SMF manifests (svccfg import) before managing them with the smf provider
- Audit new Solaris hosts for legacy_run entries and route them to an init-based profile
- Stop the legacy instance before enabling the SMF replacement to avoid split-brain daemons
When it happens
Trigger: status evaluation of a service resource (provider => 'smf') whose svcs state line reads legacy_run — typically a Solaris 10-style rc script started via /etc/rc?.d or a legacy service visible to svcs but outside SMF control.
Common situations: Migrating Solaris 10 hosts where daemons still run from rc scripts; third-party installers that start services legacy-style; manifests assuming every svcs-listed service is SMF-managed.
Related errors
- Failed to get the FMRI of the %{service} service: The patter
- Cannot query if the %{service} service is complete: The conc
- Timed out waiting for #{@resource[:name]} to transition stat
- Unmanageable state '#{state}' on service #{name}
- The pkg-get command is missing; blastwave packaging unavaila
AI-assisted analysis of puppetlabs/puppet@e227c27540 (2026-08-21).
Data as JSON: /api/errors/fd3dc11236790a78.
Report an issue: GitHub.