1.1. Short listing of SMF files and directories

• /var/svc: logs, manifests, profiles

• /lib/svc: methods, seed repository, restore_repository script

• /etc/svc: repository.db, repository backups, volatile (a tmpfs)

/var/svc/manifest/site is reserved for manifests specific to your site.

1.2. Short listing of SMF commands

• svcs(1): service status listing

• svcadm(1M): administrative actions

• svccfg(1M): property modification, can be batch or interactive mode

• svcprop(1): property reporting, suitable for scripting

• inetadm(1M):administrative and property modification for inetd services

• inetconv(1M): convert legacy inetd.conf entries to SMF manifest and service

1.3. Short listing of relevant SMF man pages

1.4. How permanent is svcadm(1M)?

Unless the "-t" option is used, svcadm(1M) enable/disable is persistent through reboots, patches, and upgrades. The "-t" option indicates that this specified state is good only until the next reboot.

1.5. Are milestones the same as run levels?

A milestone is a new mechanism made to be compatible with run-levels. Milestones define a specific state of system readiness, each with a specific set of services enabled. Before smf(5), system boot progresses from run level S to 3, executing scripts in /etc/rc?.d along the way. With smf(5), system boot does not progress from milestone to milestone, the dependency determines the order of service start.

Except for none, and all, milestones show up as services in SMF. However, the system can only be in one of the following milestones at any time:

none, single-user, multi-user, multi-user-server, all

Regardless of the state of milestone/* as shown by "svcs -a". For the system's current milestone, check the options_ovr/milestone property of svc:/system/svc/restarter:default

# svcprop -p options_ovr/milestone restarter:default

If this command returns the following error:

svcprop: Couldn't find property 'options_ovr/milestone'
for instance 'svc:/system/svc/restarter:default'.

then the system is in its default milestone.

To view the system's default milestone, see question 2.13.

Other milestones exist to declare that some set of services are ready. They are available for use as dependencies. For example, if milestone/devices is online, it indicates that device/fc-fabric and device/local have finished. Use "svcs -d <milestone>" to list the dependencies for the milestone.

1.6. Where did the output of the rc scripts go?

rc scripts are now started in the analogous milestone, and all outputs from them during boot are logged to the milestone service's log file in /var/svc/log. For example, scripts in /etc/rc3.d are run in milestone multi-user-server, invoked by start method /sbin/rc3. The output of those scripts go to /var/svc/log/milestone-multi-user-server:default.log.

• svc:/milestone/single-user:default starts /etc/rcS.d

• svc:/milestone/multi-user:default starts /etc/rc2.d

• svc:/milestone/multi-user-server:default starts /etc/rc3.d

1.7. When I run svcs -a, I see a column labeled STIME. Does that mean "Start Time"?

STIME stands for "State Time", the time when the service entered that state. It is precise to the sub-second, although only the second is printed. "svcs -a" lists services in the order that they finished starting. STIME is not authoritative, svcadm(1M) refresh will update it. To find out when a service was started, you have to look at the log.

1.8. Is SMF integrated with FMA?

No. In particular, the smf(5) doesn't send any telemetry to fmd(1M).

1.9. Can I make my service depend on a zone?

No, smf(5) doesn't have the mechanism to support dependencies on zones.

1.10. Why is "Importing service descriptions…" so slow?

It's serial and does a lot of syncing (to guard against power failure, etc). We're working on it (see CR 6351623).

1.11. svcs(1) shows me a service state with an * next to it, for example, online*, what does it mean?

It means the service is still in transition, use "svcs -v" to see the next state.

1.12. Where are SMF logs? Do I need to rotate them?

svc.startd stores log files in the /etc/svc/volatile directory in early stages of boot, before /var is mounted read-write.

SMF logs are kept in /var/svc/log. For service log files, invoke

# svcs -x <service>

This does not work for disabled services. You don't need to rotate SMF logs, it's already managed by logadm(1M), see /etc/logadm.conf. Output from the /etc/rc.?/* legacy scripts are collected in the appropriate /var/svc/log/milestone-* file.

1.13. Is there additional SMF documentation, in addition to existing man pages?

• BigAdmin SMF site

• OpenSolaris SMF site

• OpenSolaris SMF Community Discussions

• Ready-made SMF manifests

• System Administration Guide

• SMF FAQ

2.1. How can I allow user X to control service Y?

SMF uses RBAC to delegate service management responsibility. The following properties can be set:

action_authorization: can execute method; allows you to do:

• svcadm [enable | disable] -t

• svcadm refresh

• svcadm restart

• svcadm mark maintenance

• svcadm clear

value_authorization: can change values of existing property. It allows you to permanently enable or disable a service because you are changing the general/enabled property of the service.

modify_authorization: can change, add, or delete properties.

See /var/svc/manifest/network/ssh.xml for an example.

The value of these properties, a string, must be added to a user security attributed in /etc/user_attr. Here's how to allow user jdoe to enable/disable ssh:

/var/svc/manifest/network/ssh.xml:

        <property_group name='general' type='framework'>
                <!-- to start stop sshd -->
                <propval name='action_authorization' type='astring'
                                value='solaris.smf.manage.ssh' />
                <propval name='value_authorization' type='astring'
                                value='solaris.smf.manage.ssh' />
        </property_group>

        /etc/user_attr:
                jdoe::::auths=solaris.smf.manage.ssh

The string solaris.smf.manage.ssh can be any arbitrary string, but solaris.smf.manage.ssh is more descriptive than, say, "fooblat".

To see the auction_authorization authorizations for a service, run:

# svcprop -p general/action_authorization

If the service has none, you can add one with svccfg(1M)

# svccfg -s <FMRI> setprop general/action_authorization = astring: \
"solaris.smf.manage.service"
# svcadm refresh <FMRI>

To allow a user to change the properties in a certain property group, give the user value_authorization. To allow the user to modify, add or remove the properties in a certain property group, give them modify_authorization.

To allow a user to do manage any service, give him solaris.smf.manage. To give a user full control over the repository, give him solaris.smf.modify.

Give a user authorization by modifying /etc/user_attr

# echo "jdoe::::auths=solaris.smf.manage.service" >> /etc/user_attr

You can see a user's authorizations with "auths jdoe".

2.2. How do I add a dependency to an existing service?

By using svccfg(1M), let's say that you want to add a filesystem/local dependency to a service:

# svccfg -s <FMRI>
> addpg myfs-local dependency  <-- "myfs-local" is the descriptive name
> setprop myfs-local/grouping = astring: "require_all"
> setprop myfs-local/restart_on = astring: "none"
> setprop myfs-local/type = astring: "service"
> setprop myfs-local/entities = fmri: "svc:/system/filesystem/local"
> exit
# svcadm refresh <FMRI>

If you've made a mistake, invoke editprop, which will launch the $EDITOR, or vi if $EDITOR is not set. Find your mistake, correct it, and uncomment the hash at the beginning of the command. After saving and quitting the $EDITOR, the command you've uncommented is executed.

Note that svccfg import employs a syntax checker to validate your XML manifest. Interactive svccfg does no such validating and will allow you to make a mistake that would have been caught by svccfg import.

2.3. Why can't I just modify my FMRI manifest and add the following…

        <dependency name='myfs-local'
                grouping='require_all'
                restart_on='none'
                type='service'>
                <service_fmri value='svc:/system/filesystem/local' />
        </dependency>

Never modify manifests in place. This can't be stressed enough. Always use svccfg to modify or customize a service. SMF detects customizations by comparing current property values with those from the last manifest imported. If your customizations are in a manifest, then SMF will think that you have no customizations. In a future patch or upgrade, SMF may drop in a new manifest and erase all the customizations you've added in the manifest.

2.4. How do I back up the repository?

Currently the ability to take repository backup at will does not exist. 4 backup copies are taken automatically and kept in /etc/svc. You can make copies of /etc/svc/repository.db but there is a risk that such a copy won't be self-consistent if svc.configd(1M) makes a change during the copy.

2.5. How do I take a snapshot of a service's configuration?

Currently you can't take snapshots at will. There is an RFE filed to make this possible, see CR 6199307. You can use svccfg export <service> to get an XML file describing the currently running service.

2.6. Why doesn't "svccfg export apache2" work?

svccfg(1M) only exports services. In /network/http:apache2, network is the functional category, http is the service, apache2 is the instance. You can export the service using svccfg export http, the exported manifest will include the instance. Work is underway to enable svccfg to export instances, see CR 6299665.

2.7. How do I figure out who disabled this service?

Currently smf(5) does not track who does what.

2.8. How do I make SMF send me an email when a service changes state?

That level of functionality does not currently exist as of yet.

2.9. How can I take a snapshot of all of the services on my system, so I can check for changes later?

There is no ability to take snapshots at will yet. CR 6199307 has been filed to allow snapshot-at-will, and CR 6389280 has been filed to allow users to compare snapshots. The alternative is to use svccfg(1M) export to output service properties in XML files and compare those, or svccfg archive to get a full service description for all services in one XML file. Also see question 2.5.

2.10. I am in milestone single-user for some diagnostic; I want to enable some service but can't.

This is propably due to your repository not mounted as writeable, you can check this by looking at the output of mount(1M) and check the writeability of the root filesystem.

You can get around this problem by using svcadm enable -t to temporarily enable the service. Better yet, use svcadm enable -rt to also enable all your service's dependencies all at once.

2.11. How do I turn on verbose logging?

Set the options/logging property of the restarter:

# svccfg -s /system/svc/restarter:default
> addpg options application
> setprop options/logging = astring: "verbose"
> setprop options/type = astring: "framework"
> exit
# svcadm refresh /system/svc/restarter:default

Also see question 3.5 for use of boot -m verbose.

2.12. How do I delete a service?

Use svccfg delete. This will fail if the service is running. In that case, either disable the service with svcadm(1M), or use svccfg delete -f. Remove the service manifest. This last step is to avoid SMF re-enabling the service in case of a seed repository recovery when SMF re-imports manifests.

Warning: Delete services at your own risk. You might inadvertently upset a milestone or another service which depends on the service you just deleted, and the effect might not be immediately noticeable.

2.13. How do I find out what is my system's default milestone?

# svcprop -p options/milestone restarter:default

If this property does not exist, that is, you get the following error:

svcprop: Couldn't find property `options/milestone'
for instance `svc:/system/svc/restarter:default'.

then the system's default milestone is all.

The difference between the properties options/milestone and options_ovr/milestone is that the former records your default boot milestone if you have changed it since last boot. The latter records your current milestone if you've used svcadm to transition to another milestone since last boot. Your current milestone and your default boot milestone are not necessarily the same. The system always returns to its default milestone every time it boots.

If options/milestone does not exist, the default milestone is all.

If options_ovr/milestone does not exist, the current milestone is the default milestone.

2.14. How do I leave my current milestone?

If you want to change run-level, use /sbin/init. Milestones are compatible with run-levels, but are not run-levels. See Question 1.5. Changing the system's milestone does not change its run level.

If you've used svcadm milestone or boot -m milestone= to get to where you are now, you can use:

# svcadm milestone <new milestone>

to go to a new milestone.

2.15. How do I create my own milestone?

You can't create milestones that you can boot to. The milestones which svcadm milestone accepts are hardcoded into svcadm(1M) and svc.startd(1M). See question 1.5 for the milestones that the system can be in.

You can create a milestone to declare that a set of services is ready. Services which have milestone in their name are treated like any other services.

2.16. How do I find out which processes are associated with a service?

# svcs -p
# svcs -pv

The latter will also return contract IDs.

2.17. How do I find out which service is associated with a process?

# ps -e -o ctid,args | grep <process_name>
# svcs -o ctid,fmri | grep <pid_found_with_previous_command>

2.18. How do I see the process privilege set for my service?

Find a process associated with your service, and use

# ppriv -S <PID>

2.19. How do I assign my service to run in a project?

See the work-around for CR 6517270:

Specify all required properties directly. In this example, we're trying to have the smtp:sendmail service start in the sendmail(1M) project.

First, check if the property you're trying to set is already defined for the service:

# svcprop -p start/project <FMRI>

If this property is set to a value (like :default), do the following to change the project:

# svccfg -s <fmri> setprop start/project = sendmail
# svcadm refresh sendmail; svcadm restart sendmail

If it isn't set, specify all required properties.

# svccfg -s sendmail setprop start/project = astring: sendmail
# svccfg -s sendmail setprop start/user = astring: root
# svccfg -s sendmail setprop start/group = astring: :default
# svccfg -s sendmail setprop start/working_directory = astring: :default
# svccfg -s sendmail setprop start/resource_pool = astring: :default
# svccfg -s sendmail setprop start/supp_groups = astring: :default
# svccfg -s sendmail setprop start/privileges = astring: :default
# svccfg -s sendmail setprop start/limit_privileges = astring: :default
# svccfg -s sendmail setprop start/use_profile = boolean: false
# svcadm refresh sendmail; svcadm restart sendmail

See question 4.9 on how to create a +method_context+1 block in a manifest. See question 4.10 on how to assign a service to a project in a manifest.

2.20. How do I set environment variables for my service?

Set one variable:

# svccfg -s <service name> setenv -m <method name> MYVAR value

Set one variable to multiple values:

# svccfg -s <service name> setenv -m <method name> MYVAR "val1 val2"

Set multiple variables:

# svccfg -s <service name> setenv -m <method name> MYVAR1 val1
# svccfg -s <service name> setenv -m <method name> MYVAR2 val2

<method name> can be start, stop, or refresh. Use unsetenv to unset variables. Refresh the service to commit the changes.

3.1. Why does svcs -x report print/server after a fresh install?

Services which depend on svc:/application/print/server:default are delivered as enabled, but svc:/application/print/server:default is delivered as disabled. This results in the dependent services being placed in the offline state, which svcs -x reports as an error.

3.2. "svc:/application/print/server:default" actually has 3 dependents. Despite it being disabled, only two dependents are offline, one dependent (milestone/multi-user) is actually online. How is this possible?

There are 4 types of dependencies. One may think of them in terms of gradient, how much does a service need from a dependency before it considers that dependency satisfied. The relationship print/server has with milestone/multi-user is of type optional_all. This means that print/server can be in the disabled state and still allow milestone/multi-server to run. The relationship print/server has with the other 2 services are of type require_any and require_all, which are satisfied when print/server is online or degraded.

3.3. Why is svc.configd(1M) is taking up a lot of memory?

You may be running into:

CR 6304200: svc.configd(1M) becomes a heavyweight, weighing in at 500MB
The workaround is to kill svc.configd, svc.startd(1M) will start a new
one.  This is fixed in patch 118833-36.

3.4. Why is svc.configd(1M) is taking up a lot of CPU?

You may be running into

CR 6237669: _check_services() SMF logic causing svc.configd overwork.
If you are frequently mounting NFS filesystems, every mount is causing
SMF to unnecessarily refresh a set of related services and to consume
a lot of CPU doing so.  This is fixed in patch 118833-36.

svc.configd(1M) only does work for its clients, and svc.startd(1M) is its biggest client. If this is not the bug you are running into, check svc.startd.

3.5. My system hangs during boot. What should I do?

ok> boot -m verbose, milestone=none
(login)
# svcadm milestone all

3.6. I screwed up my service. What should I do?

If a single service is broken, first run svcs -x <FMRI>, this may tell you what has gone wrong. Check the log files in /var/svc/log/service-name.log.

SMF keeps a snapshot of the last time your service successfully started. As a last resort, you can roll back to that snapshot.

# svccfg -s service:instance
> selectsnap start
> revert
> exit
# svcadm refresh service:instance

3.7. I screwed up my repository so bad I can't even boot the system to restore an old repository backup. What do I do?

If neither boot -s nor boot -m milestone=none provides a shell for you, then you'll have to boot net or boot from a CD. Then mount the root filesystem and run

# /lib/svc/bin/restore_repository -r /path/to/root

3.8. svcs -x says service Y was "disabled by an administrator", but I didn't disable it.

SMF does not record who does what, it assumes that the service was disabled by an administrator. Incidentally, you only see this when using svcs -x <FMRI>, invocations of svcs(1) or with the -l or -v option will just show the the state as being disabled.

3.9. When I set {nis/client, nis/server} to be enabled in site.xml, why is it not enabled after install?

If you installed your system using jumpstart, the first time your system boots, site.xml is applied and then /lib/svc/method/sysidtool-system resets the name service according to the sysidcfg(4) file, disables {nis/client, nis/server} and undoes what site.xml has done. This is a bug, see CR 6421535.

To get around this, create another service that depends on sysidtool-system which re-applies site.xml.

3.10. Why hasn't my service started even though the file: dependency is now fulfilled?

There is no file event to signal SMF that a file has come online. If SMF tries to start your service and finds that a file: dependency is not satisfied, it continues to think so forever. See CR 5106165.

3.11. Why is network/physical in maintenance?

One possible reason is that you may have aliased your hostname to 127.0.0.1, the loopback address, and then used that hostname in your /etc/hostname.interface file.

3.12. Why doesn't svcs -x know why my /system/console-login is in the offline state?

If you boot to milestone none and from there go to milestone all (see question 3.5) without exiting the sulogin shell, svc.startd(1M) keeps console-login in the offline state. svcs -x sees that all of console-login's dependencies are satisfied, and can't figure out why console-login is offline. Your system is fine. svc.startd(1M) will notice when you've logged out of your sulogin shell and will start console-login properly after that.

In another situation, if you have a file: dependency which was not satisfied when your service start, but the file is present when you run svcs -x, SMF reports that it can't determine the reason why your service is offline. You should refresh your service (see question 3.9).

3.13. I just jumpstarted a system and I get this message after it boots

svc:/milestone/multi-user-server:default
(multi-user plus exports milestone)
State: offline since Wed Feb 08 11:44:58 2006
Reason: Dependency svc:/system/install is absent.

However, I can't find svc:/system/install anywhere.

system/install is an service that gets added to the repository after the install is complete, but before the reboot. This service is not needed if you build your system using jumpstart, and it is removed before the reboot. If your finish script has a reboot call, and your system reboots before SMF has a chance to completely remove system/install, you will get this.

Don't call reboot in your jumpstart finish script. To fix, use svccfg(1M) to remove the dependency from multi-user-server milestone.

# svccfg -s multi-user-server listpg

Find the dependency name for svc:/system/install, and delete it.

# svccfg -s multi-user-server delpg

4.1. How do I write an SMF manifest?

The same way you write an rc script: start with Sun-delivered manifests as examples. Copy and cut and paste as you need.

Manifests you can use as examples:

• /var/svc/manifest/system/utmp.xml for a simple standalone daemon

• /var/svc/manifest/system/coreadm.xml for a service which run once at boot

• /var/svc/manifest/network/telnet.xml for an inetd-managed service

• /var/svc/manifest/network/http-apache2.xml for a service with dependencies

• /var/svc/manifest/network/ssh.xml for a service which uses RBAC authorization

The DTD - Document Type Definition, is /usr/share/lib/xml/dtd/service_bundle.dtd.1, and is defined at the top of each manifest. You need at least 3 things: the service name, the start and stop method, and dependencies.

The Service Developer Introduction is very helpful, you can find here.

The collection of manifest written by the SMF user community is available on the opensolaris.org "SMF Methods and Manifests" site, located here.

4.2. How do I check my manifest for syntax error?

svccfg import has a built-in validator, and won't import your manifest if it has errors. Use svccfg validate <XML file> to check your syntax without importing the file. You can also use xmllint(1M):

# xmllint --valid <XML file>

4.3. Which filesystem service should I depend on?

You should at least depend on, directly or indirectly, filesystem/minimal. If your service requires one or more files, then you should also depend, directly or indirectly, on the filesystem service that will make that file available before your service starts.

svcs:/system/filesystem/root /usr is mounted
svcs:/system/filesystem/usr / and /usr are read-write
svcs:/system/filesystem/minimal /var, /var/adm, /var/run, and /tmp tmp are mounted
svcs:/system/filesystem/local all other filesystems are mounted

4.4. What do I need in my manifest in order delegate service administration to a user?

See question 2.1 You need:

<property_group name='general' type='framework'>
        <propval name='action_authorization' type='astring'
                        value='solaris.smf.manage.service' />
        <propval name='value_authorization' type='astring'
                        value='solaris.smf.manage.service' />
</property_group>

modify_authorization are typically given per-property group, instead of in the general property group.

Don't forget to modify /etc/user_attr to add the value string to the user security profile:

/etc/user_attr:
        jdoe::::auths=solaris.smf.manage.ssh

4.5. What do I need in my manifest to keep my service from restarting every time it core dumps or a child process exits?*

<property_group name='startd' type='framework'>
        <propval name='ignore_error' type='astring'
                value='core,signal' />
</property_group>

4.6. What are method tokens and how are they used?

svc.startd(1M) supports the following method tokens:

% %%
%r Name of the restarter, such as svc.startd
%m Name of the method, such as start or stop
%s Name of the service
%i Name of the instance
%f FMRI of the instance
%{prop[:,]} Value(s) of a property.

See the smf_method(5) manpage for more.

4.7. What does a timeout_seconds value of "0" or "-1" mean?

"0" or "-1" denote infinite timeout; we recommend you use "0" and not "-1".

4.8. What is the inetconv property group used for?

It's a record of the original inetd.conf(4) line the inetconv(1M) used to generate the manifest. You don't need it if you're writing a new manifest.

4.9. How do I restrict my service to have only the privileges it needs?

You need to find out what privileges your service needs, then construct a method context to tell SMF to start and stop the service with only those privileges.

Download the privdebug.pl script

Instruction on how to use privdebug.pl is beyond the scope of this FAQ, but can be found in the "Privilege Debugging in the Solaris 10 Operating System" Blueprint.

After the privdebug exercise you will have a set of privileges required for the application to start and to stop. You will add to, or subtract from the set of basic privileges to create a set of privileges that your application uses.

To see the default basic set of privileges:

# ppriv -l basic

For example, if your application needs:

proc_fork, proc_exec, net_privaddr to start
proc_fork, proc_exec, and proc_session to stop

and your basic set of privilege contains:

file_link_any, proc_fork, proc_exec, proc_info, proc_session

To start you need to:

subtract file_link_any, proc_info, proc_session FROM basic
add net_privaddr TO basic

To stop you need to:

subtract file_link_any, proc_info FROM basic

Insert a method_context block inside your exec_method block in your service manifest, as demonstrated below:

<exec_method
        type='method'
        name='start'
        exec='/path/to/method start'
        timeout_seconds='0' >
        <method_context>
        <method_credential
                user='someuser'
                privileges='basic,!file_link_any,!proc_info,
                                !proc_session,net_privaddr'/>
        </method_context>
</exec_method>

<exec_method
        type='method'
        name='stop'
        exec='/path/to/method stop'
        timeout_seconds='0' >
        <method_context>
        <method_credential
                user='someuser'
                privileges='basic,!file_link_any,!proc_info'/>
        </method_context>
</exec_method>

Common mistakes include bracketing with <exec_method> </exec_method>, and writing "/>" after timeout_seconds instead of ">". The correct way is

<exec_method
        ... properties >
        <method_context>
        <method_credential
                ... properties />
        </method_context>
</exec_method>

Also, setting a value for user is required. Import the manifest and check your service. See question 2.18 for how to view your service's privilege set.

4.10. How do I assign my service to run in a project in a manifest?

<exec_method
        type='method'
        name='start'
        exec='/path/to/method start'
        timeout_seconds='0' >
        <method_context
                project=projectname' >
        <method_credential
                user='someuser' />
        </method_context>
</exec_method>

4.11. Where do I put manifests that I've written?

Manifests for both Solaris and third-party services should be installed in the appropriate subdirectory under /var/svc/manifest. Site-local service manifests should be installed under /var/svc/manifest/site. (Manifests can be stored in other locations, but only manifests stored under /var/svc/manifest will be automatically imported by SMF).

svc.startd(1M) methods invoke executables, and these executables can be installed wherever you would normally place other executables. Following the conventions defined in filesystem(5), we recommend putting method scripts which are intended for use by only SMF — i.e. not by a human user — under the relevant "lib" directory. Method scripts for Solaris-provided methods are stored in /lib/svc/method. Method scripts for third-party services should be stored under /opt/packagename (/opt/packagename/lib/svc/method is recommended for consistency, but isn't required). Method scripts for site-local services should be stored in whatever tree the site reserves for its libraries/binaries.

special thanks to Christine Tran, David Bustos, Bernd Schemmer, and all contributing SMF community members.

This page represents a list of commonly asked questions, with corresponding answers, regarding the Service Management Facility introduced within Solaris 10. The FAQ is intended to be a "living document" that enables users and developers to increase their understanding of smf(5), the development of service manifests,and knowledge of the administrative command-line utilities.

We strongly encourage and welcome contribution from the SMF Community. Please send your feedback, in addition to Q&A contributions to smf-discuss AT opensolaris DOT org. Please include "SMF FAQ" within your "Subject: " line.