SMF: starting/controlling services

Services are managed by svcadm. The most common commands are

svcadm enable SERVICE

svcadm disable SERVICE

Note that enable and disable are persistent. If you enable a service it will be brought back up after a
reboot. Similarly with disabling.

If you want to stop a service but have it come back up after the next reboot, use

To look at services, two common commands are

svcs {lists summary of all}

svcs -l SERVICE {details on one service}

Solaris 10 still pays attention to /etc/rcN.d, but services defined there are "legacy", and can't be fully
monitored and controlled.

To define a service, you create an XML file that specifies dependencies, and methods to start and
stop it.

Then you do "svccfg import FOO.xml".

Normally the XML file is written to create an instance but not enable it. So if the import works, you
would need to do "svcadm enable SERVICE" to start it.

A good way to start writing the XML file is to look at existing ones. They are in subdirectories of
/var/svc/manifest.

Sun suggests system/utmp.xml as a simple example.

If you add services, you probably want to put your .xml files in /var/svc/manifest and your scripts in
/lib/svc/method. That way anyone who needs to work with the system can find them, just as they
now know to look in /etc/init.d for all startup scripts. However I suggest making those symbolic links
to files that are actually in /usr/local/svc/manifest and /usr/local/svc/method. That way you won't
lose your information in a system reinstallation.

Note that if all processes started by a service die, the system will try to restart the service by doing a
stop and then a start.

You can also define a "refresh" action, which prods a service if a configuration file changes.

You'll always need an XML header. Comments can be added in normal XML fashion.

<?xml version="1.0"?>

<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">

Define the service_bundle.

<service_bundle type='manifest' name='CSWmypkg:myserver'>

Type => manifest (also optional for profile and archive

Name => PKGname:appname

The service name and version.

<service

name='network/myserver'
 type='service'

version='1'>

Name => Name to be refered, canonical name.

Type => Type of service, service, restarter or milestone.

Version => Integer Version for this service

Define the instance.

<instance name='default' enabled='false'>

Name => canonical name for this instance of the service

Enabled => Inital state of the instance.

Define the interface stability.

<stability value='Evolving' />

value => Interface Stability according to attributes(5):

Stability Release Comments

---------------------------------------------------------------------

Standard Major (x.0) Actual or de facto.

Stable Major (x.0) Incompatibilities are exceptional.

Evolving Minor (x.y) Migration advice might accompany

an incompatibility.

Unstable Minor (x.y) Experimental or transitional:

incompatibilities are common.

External Micro (x.y.z) Not controlled by Sun:

common.

Obsolete Minor (x.y) Deprecated interface: likely to be

removed in a future minor release.

Define your dependancies.

<dependency name='loopback'

grouping='require_all'

restart_on='error'

type='service'>

<service_fmri value='svc:/network/loopback:default'/>

</dependency>

name => Name of this dep.

grouping => Relationship of the listed FMRIs to this service:

-> "require_all" : All listed FMRIs must be online.

-> "require_any" : Any of the listed FMRIs must be online

-> "exclude_all" : None of the FMRIs can be online.

-> "optional_all" : Listed FMRIs are either online or unable to come online, either

due to being disabled, misconfigured or unable to start due

to deps.

Restart_on => Type of event from the FMRI that this service should be restarted for, being:

-> error : Hardware fault

-> restart : Retarted if the dep is restarted.

-> refresh : Restarted if the dep is restarted or refreshed for any reason.

-> none : Nothing, never start the service to to a dep state change.

type => Type of the dep, "service" or "path"

FMRI's are simple little fellows.

<service_fmri value='svc:/network/loopback:default'/>

value => the FMRI

Define your methods, normally one each for "start", "stop", and "refresh".

<exec_method

type='method'

name='start'

exec='/usr/bin/serverd'

timeout_seconds='60' />

type => Type of method, "method" or "monitor"

name => Name of execution method, a defined interface of the restarter.

exec => A string identifying the action to take.

timeout_seconds => Duration to wait for the method to complete.

delete => If in the repo, the property group for this method should be remoed.

Perhaps even specify the restater, not needed.

<restarter>

<service_fmri value='svc:/network/inetd:default' />

</restarter>

Specifies the restarter for this service, by default svc.startd(1M)

Method contexts can be handy to setup the enviroment (or "context") in which your service runs.
 <method_context>

<method_credential user='root' group='root' />

<method_environment>

<envvar name="PATH" value="/bin:/opt/csw/bin" />

</method_environment>

</method_context>

envvar -> name: Env name

value: Env value

method_environment -> (continas multiple envvar tags)

method_profile -> name

method_credential -> user

-> group

-> supp_groups

-> privileges

-> limit_privileges

Example of inetd property groups.

<property_group name='inetd' type='framework'>

<stability value='Evolving' />

<propval name='name' type='astring' value='telnet' />

<propval name='endpoint_type' type='astring' value='stream' />

<propval name='proto' type='astring' value='tcp6' />

<propval name='wait' type='boolean' value='false' />

<propval name='isrpc' type='boolean' value='false' />

</property_group>
Should it start by default?

<create_default_instance enabled='false' />

A flag element indicating that an otherwise empty default instance

of this service (named "default") should be created at install, with

its enabled property set as given.

Should there be one, and only one instance?

<single_instance />

A flag element, meaning only one instance can be started.

[ Typically used with <create_default_instance> ]

There you go, some of my chopped up notes that might be handy. Mind you, this isn't official, just my
scribbled notes that I thought might be helpful to someone or at least get ya fired up enought to
dabble into SMF for yourself. If anyone finds this terribly useful I'll form it into a pretty LaTeX
document at some point.