SMF/ Predictive Self Healing: svcs(1)

Perhaps the most often used tool in the SMF world is svcs. It's the master "observational" tool, used for querying the state and properties of all the services on your machine.

Used with no options, it simply lists all services that are enabled. Enabled means that the administrator wishes these services to be running. They may not be, because their dependencies are not met, they failed to start correctly, or some other reason. But they're the services that should be running.

# svcs
STATE          STIME    FMRI
legacy_run     Sep_17   lrc:/etc/rcS_d/S10pfil
legacy_run     Sep_17   lrc:/etc/rcS_d/S29wrsmcfg
legacy_run     Sep_17   lrc:/etc/rc2_d/S72autoinstall
legacy_run     Sep_17   lrc:/etc/rc2_d/S72directory
legacy_run     Sep_17   lrc:/etc/rc3_d/S84patchserver
legacy_run     Sep_17   lrc:/etc/rc3_d/S90samba
online         Sep_17   svc:/system/svc/restarter:default
online         Sep_17   svc:/network/loopback:default
online         Sep_17   svc:/network/physical:default
online         Sep_17   svc:/system/filesystem/root:default
online         Sep_17   svc:/network/ssh:default
online         Sep_17   svc:/system/coreadm:default
online         Sep_17   svc:/milestone/single-user:default
online         Sep_17   svc:/system/system-log:default
online         Sep_17   svc:/system/utmp:default
online         Sep_17   svc:/system/filesystem/local:default
online         Sep_17   svc:/milestone/name-services:default
online         Sep_17   svc:/network/inetd:default

Now, I've edited this list quite a bit. As it stands now, a freshly installed Solaris machine will come up with 108 running services. I'm sure this number will change a bit before we ship.

What can we see above? First, we see the legacy services, which I've mentioned in a previous post. These are the scripts that still exist in the rcX directories. For example, you can see above that /etc/rc3.d/S90samba was started. Since these services haven't been converted to SMF services, they won't be automatically restarted, but they'll be started, just like they were in previous incarnations of Solaris. If you have your own personal scripts, this is where you'll see them.

Below this you start to see online SMF services, such as ssh and inetd. You'll also see "milestones", which are services that are simply lists of dependencies that represent a system state, such as "single-user", or "local filesystems" as being available.

Let's take a look at some of the command line options that make svcs so powerful and useful.


The -a option means "all". It shows all the services on a machine, whether they're enabled or not.

# svcs -a
STATE          STIME    FMRI
legacy_run     Sep_17   lrc:/etc/rcS_d/S10pfil
legacy_run     Sep_17   lrc:/etc/rcS_d/S29wrsmcfg
disabled       Sep_17   svc:/application/print/server:default
disabled       Sep_17   svc:/network/nfs/server:default
disabled       Sep_17   svc:/network/time:default
disabled       Sep_17   svc:/network/talk:default
online         Sep_17   svc:/system/svc/restarter:default
online         Sep_17   svc:/network/loopback:default
online         Sep_17   svc:/network/physical:default

This listing will show you all of the services seen in svcs, plus all the disabled services. Solaris 10 ships with most networking services turned off, for security purposes. You'll see above things like being an nfs server or a print server are also off by default. They can be enabled simply using svcadm, which will be the subject of a later post.

Now we'll start to take a look at how using svcs can be useful in analyzing a service.


The -d option to svcs shows which services this service depends on. Let's take a real world example. Say that for some reason, inetd isn't running on your machine, and you want to look at what it depends on.

# svcs -d network/inetd
STATE          STIME    FMRI
online         Sep_17   svc:/network/loopback:default
online         Sep_17   svc:/network/physical:default
disabled       Sep_17   svc:/network/rpc/bind:default
online         Sep_17   svc:/milestone/single-user:default
online         Sep_17   svc:/system/filesystem/local:default
online         Sep_17   svc:/milestone/name-services:default

You can see above that inetd depends on networking, being in single user mode, local files, and name services. And also on rpcbind, which is disabled. You'll know that you need to enable rpcbind to get inetd to run. And since we have dynamic dependency checking with SMF, as soon as you enable rpcbind, inetd will come online.


The -D option to svcs shows all the services that depend ON a given service. Again, for a real world example, let's take a look at rpcbind. Say you were considering disabling rpcbind, and you wanted to know what effect this would have on your system.

# svcs -D network/rpc/bind
STATE          STIME    FMRI
disabled       Sep_17   svc:/network/nis/server:default
disabled       Sep_17   svc:/network/nfs/client:default
disabled       Sep_17   svc:/network/rpc/bootparams:default
disabled       Sep_17   svc:/network/nfs/server:default
online         Sep_17   svc:/network/rpc/keyserv:default
online         Sep_17   svc:/network/inetd:default
online         Sep_17   svc:/network/nis/client:default
online         Sep_17   svc:/milestone/multi-user:default
online          0:42:34 svc:/network/nfs/cbd:default
online          0:42:34 svc:/network/nfs/mapid:default
online          1:26:47 svc:/network/nfs/nlockmgr:default
online          1:26:47 svc:/network/nfs/status:default

Again, I've removed several lines for brevity, but you can see that there are several disabled services that depend on rpcbind, and quite a few online services. Including inetd, your ability to be a nis server, the multi-user milestone, and others. So you can see that disabling rpcbind would have a significant effect on your machine, and you're able to know \*exactly\* how your system will be affected.


Say you want to know a general "overview" of one of your services. svcs -l (list) shows the relevent stats on a service, including who its restarter is, who it depends on, what its state is, etc.

# svcs -l network/inetd:default
fmri         svc:/network/inetd:default
enabled      true
state        online
next_state   none
restarter    svc:/system/svc/restarter:default
contract_id  43 
dependency   require_all/none svc:/milestone/single-user (online)
dependency   optional_all/error svc:/network/rpc/bind (online)
dependency   optional_all/error svc:/network/physical (online)
dependency   require_all/error svc:/system/filesystem/local (online)
dependency   require_all/error svc:/network/loopback (online)

# svcs -l network/telnet:default
fmri         svc:/network/telnet:default
enabled      true
state        online
next_state   none
restarter    svc:/network/inetd:default
contract_id  128

The two examples above show inetd and telnet. You can see that they're both enabled and online. You can also see that inetd is restarted by the master restarter, but telnet is restarted by inetd. inetd has several dependencies, while telnet has none (other than inetd running).

You'll notice that inetd has two different types of dependencies, optional and require. While I'll go into types of dependencies in another post, it's helpful to note that "require" means that that dependency must be online, while "optional" means that it has to be online only if it's enabled.


Sometimes you might want to know what processes are controlled by a service. The -p (process) option gives you the pid, start time, and name of all the processes started by a service. For example, sendmail:

# svcs -p network/smtp:sendmail
STATE          STIME    FMRI
online         Sep_17   svc:/network/smtp:sendmail
               Sep_17        452 sendmail
               Sep_17        453 sendmail

You can see above that sendmail has two processes on my machine, both started on Sept 17th.

One last example I'll show is how svcs can be useful for scripting purposes.

-H, -o

The -H option means "don't show column headings", and -o is used to pick output columns. Say you wanted to write a perl script that took services in a certain state, and performed an action upon them.

[straylight] % svcs -H -o state,fmri
legacy_run     lrc:/etc/rcS_d/S10pfil
legacy_run     lrc:/etc/rcS_d/S29wrsmcfg
legacy_run     lrc:/etc/rcS_d/S55fdevattach
online         svc:/system/svc/restarter:default
online         svc:/network/loopback:default
online         svc:/network/physical:default
online         svc:/system/filesystem/root:default

This way, you're telling svcs to output all the enabled services, showing only their state and FMRI, without the header. This can be fed into a script that looks for services that are "degraded" or in "maintenance" mode, and emails the administrator, for example.

Next time, we'll take a look at svcadm, and how to administer a system by enabling and disabling services. As always, comments and questions are welcome.



SMF looks nice. Is there any documentation released yet ? A clear description of how SMF works internally would be helpful. To answer questions like: How does SMF work ? What is the relation between SMF and init ? Is inittab still used ? How do you enable a new service ? How do you convert services controlled by rc?.d scripts to SMF services ? Has anything related to runlevels changed ? Vlad.

Posted by Vlad Grama on September 20, 2004 at 09:18 PM PDT #

smf looks strangly like daemontools (like used by qmail) is there any similarity between the two or is pure coincidence?

Posted by xtra on September 21, 2004 at 06:39 AM PDT #

Vlad: Thanks for the comments. I'm planning on addressing most of your questions in the upcoming posts. Some quick answers are that init starts SMF, and run levels still exist, but it's preferable to use our milestone services like "single user", "multi user", etc.

Enabling a service is done with svcadm, which will be my next post. Converting services will also be a post, but the short answer is that you create a manifest that describes the service, in terms of its dependencies and how to start/stop it.

Thanks for the suggestions, I'll keep trying to post as often as I have time to!

Posted by Tobin Coziahr on September 21, 2004 at 11:43 AM PDT #


I'd never heard of daemontools before, so I went and took a look. daemontools have process starting and restarting, but they can't track multiple processes using contracts the way we can. And that's about all they can do.

Above and beyond starting and restarting, SMF has the property repository that I've mentioned, dynamic dependency evaluation, the ability to eliminate configuration files scattered all over a system, and all the other features I've mentioned so far in the blog.

So the short answer is that it's pure coincidence. And SMF is far, far more powerful.

Posted by Tobin Coziahr on September 21, 2004 at 11:50 AM PDT #

Post a Comment:
Comments are closed for this entry.



« January 2017