Adoptable Cookbooks List

List of Adoptable Cookbooks

Supermarket Belongs to the Community


Select Badges

Select Supported Platforms


smf (29) Versions 1.0.0


cookbook 'smf', '= 1.0.0'
cookbook 'smf', '= 1.0.0', :supermarket
knife supermarket install smf
knife supermarket download smf
Quality -%



Service Management Facility (SMF) is a tool in many Illumos and Solaris-derived operating systems that treats services as first class objects of the system. It provides an XML syntax for declaring how the system can interact with and control a service.




Requires the RBAC cookbook, which can be found at

Processes can be run inside a project wrapper. In this case, look to the Resource Control cookbook, which can be found at Note that the SMF LWRP does not create or manage the project.


  • user - User to run service commands as
  • group - Group to run service commands as
  • project - Name of project to run commands in
  • start_command
  • start_timeout
  • stop_timeout
  • restart_command - defaults to stop_command, then start_command
  • restart_timeout
  • duration - Can be either contract, wait, transient or child, but defaults to contract. See the Duration section below.
  • environment - Hash - Environment variables to set while running commands
  • service_path - defaults to /var/svc/manifest
  • manifest_type - defaults to application
  • credentials_user - deprecated in favor of user


smf "my-service" do
  user "non-root-user"
  start_command "my-service start"
  start_timeout 10
  stop_command "pkill my-service"
  stop_command  5
  restart_command "my-service restart"
  restart_timeout 60
              "RAILS_ENV" => "staging"
  locale "C"
  manifest_type "application"
  service_path  "/var/svc/manifest"

service "my-service" do
  action :enable

service "my-service" do
  action :restart

Provider Actions

:install (default)

This will drop a manifest XML file into #{service_path}/#{manifest_type}/#{name}.xml. If there is already a service with a name that is matched by then the FMRI of our manifest will be set to the FMRI of the pre-existing service. In this case, our properties will be merged into the properties of the pre-existing service.

In this way, updates to recipes that use the SMF provider will not delete existing service properties, but will add or overwrite them.

Because of this, the SMF provider can be used to update properties for services that are installed via a package manager.



Resource Notes

user, working_directory and environment

SMF does a remarkably good job running services as delegated users, and removes a lot of pain if you configure a service correctly. There are many examples online (blogs, etc) of users wrapping their services in shell scripts with start, stop, restart arguments. In general it seems as if the intention of these scripts is to take care of the problem of setting environment variables and shelling out as another user.

The use of shell scripts to wrap executables is unnecessary with SMF, as it provides hooks for all of these use cases. When using user, SMF will assume that the working_directory is the user's home directory. This can be easily overwritten (to /home/user/app/current for a Rails application, for example). One thing to be careful of is that shell profile files will not be loaded. For this reason, if environment variables (such as PATH) are different on your system or require additional entries arbitrary key/values may be set using the environment attribute.


There are several different ways that SMF can track your service. By default it uses contract. Basically, this means that it will keep track of the PIDs of all daemonized processes generated from start_command. If SMF sees that processes are cycling, it may try to restart the service. If things get too hectic, it may think that your service is flailing and put it into maintenance mode. If this is normal for your service, for instance if you have a master that occasionally reaps processes, you may want to specify additional configuration options.

If you have a job that you want managed by SMF, but which is not daemonized, another duration option is transient. In this mode, SMF will not watch any processes, but will expect that the main process exits cleanly. This can be used, for instance, for a script that must be run at boot time, or for a script that you want to delegate to particular users with Role Based Access Control. In this case, the script can be registered with SMF to run as root, but with the start_command delegated to your user.

A third option is wait.

A fourth option is child.


Sometimes you have a case where your service behaves poorly. The Ruby server Unicorn, for example, has a master process that likes to kill its children. This causes core dumps that SMF will interpret to be a failing service. Instead you can ignore ["core", "signal"] and SMF will stop caring about core dumps.

Property Groups

Property Groups are where you can store extra information for SMF to use later. They should be used in the following format:

smf "my-service" do
  start_command "do-something"
    "config" => {
      "type" => "application",
      "my-property" => "property value"

type will default to application, and is used in the manifest XML to declare how the property group will be used. For this reason, type can not be used as a property name (ie variable).



smf "unicorn" do
  start_timeout 300
  restart_command ":kill -SIGUSR2"
  restart_timeout 300
  working_directory "/home/app_user/app/current"
    "config" => {
      "rails_env" => rails_env

This is especially handy if you have a case where your commands may come from role attributes, but can only work if they have access to variables set in an environment or computed in a recipe.

Working Examples

Below are some of the working examples using the SMF cookbook.

Shared Helpers

These live in a library provider somewhere, and help start/stop pid-based processes. This strategy may be required when using the wait duration.

module ProcessHelpers
  def start_helper(cmd)
  def stop_helper(pid, sig = :term)


Here is an example that uses duration wait. Because of this, SMF does not watch pids in a contract, and the stop_command needs to figure out what processes are running.

class Chef::Resource::Smf
  include ::ProcessHelpers

rails_env     = node[:rails_env]
user          = node[:app][:user]


smf "unicorn" do
  user user
  start_timeout 90
  stop_command stop_helper(unicorn_pid, :term)
  stop_timeout 30
  duration "wait"
  working_directory "#{current_path}"

This example, while more verbose, uses the default duration of contract, and so SMF can take care of pid management. We are able to use :kill in the stop and restart commands.

rails_env =
garbage_collection_settings = {
  "RUBY_GC_MALLOC_LIMIT": 50000000,
  "RUBY_HEAP_MIN_SLOTS": 500000,

smf "unicorn" do
  user user

  start_timeout 90
  stop_timeout 30
  restart_command ":kill -SIGUSR2"
  restart_timout 120


  ## signals to children.
  ignore ["core","signal"]
    "config" => {
      "rails_env" => rails_env,
      "current_path" => current_path
  working_directory current_path


class Chef::Resource::Smf
  include ::ProcessHelpers

rails_env     = node[:rails_env]
user          = node[:app][:user]

sidekiq_yml   = "#{dir}/config/sidekiq.yml"
sidekiq_log   = "#{dir}/log/sidekiq.log"

smf "sidekiq" do
  user user
  start_timeout 30
  stop_command stop_helper(sidekiq_pid, :term)
  stop_timeout 15
  working_directory "#{dir}"

sidekiq_monitor_run_path    = "#{dir}/"

smf "sidekiq-monitor" do
  user user
  start_timeout 30
  stop_command stop_helper(sidekiq_monitor_pid, :term)
  stop_timeout 15
  working_directory "#{dir}"

No quality metric results found