Why doesn’t Solaris SMF aware service start on boot?

A quick hint on how to find a possible root cause why a newly imported service doesn’t auto start on system reboot. So… You’ve just imported service’s manifest, rebooted the system and noticed the service is still in the offline state:

svccfg import service_manifest.xml
init 6
svcs service_name

STATE          STIME    FMRI
offline        15:55:52 svc:service_name:default

A good start is to use “svcs -l service_name” to check that all service instances upon your service depends (used ssh as an example):

$ svcs -l ssh
fmri         svc:/network/ssh:default
name         SSH server
enabled      true
state        online
next_state   none
state_time   Wed Nov 06 15:55:01 2013
logfile      /var/svc/log/network-ssh:default.log
restarter    svc:/system/svc/restarter:default
contract_id  60
dependency   require_all/none svc:/system/filesystem/local (online)
dependency   optional_all/none svc:/system/filesystem/autofs (disabled)
dependency   require_all/none svc:/network/loopback (online)
dependency   require_all/none svc:/network/physical (online)
dependency   require_all/none svc:/system/cryptosvc (online)
dependency   require_all/none svc:/system/utmp (online)
dependency   require_all/restart file://localhost/etc/ssh/sshd_config (online)

So you’ve checked the logs and all the dependencies and still don’t fully understand why the new service did start. I feel your pain as I was in exactly the same situation. Take a look at the services that depend on your service (again I will use ssh as an example):

svcs -D ssh
STATE          STIME    FMRI
online         15:55:51 svc:/milestone/multi-user-server:default

Or instead, the services it depends upon:

svcs -d svc:/application/management/sma:default
STATE          STIME    FMRI
online         15:54:38 svc:/milestone/name-services:default
online         15:54:49 svc:/system/cryptosvc:default
online         15:54:50 svc:/milestone/network:default
online         15:54:51 svc:/system/filesystem/local:default
online         15:55:00 svc:/milestone/sysconfig:default
online         15:55:01 svc:/system/system-log:default
online         15:55:06 svc:/network/rpc/rstat:default

If you don’t see “milestone” being mentioned in the output then that is definitely the problem and explains why the service didn’t start when you rebooted the system. Basically it’s the same as if you hadn’t run “chkconfig service_name on” on a RedHat-like or “update-rc.d serice_name defaults” on a Debian-like Linux system. Refer to the table below to get an idea which run level corresponds to what milestone:

Run Level SMF Milestones
Smilestone/single-user:default
2milestone/multi-user:default
3milestone/multi-user-server:default

For the sake of completeness here is a full list of all milestones available (at least on the system I have near me):

svcs "milestone*"
STATE          STIME    FMRI
disabled       15:54:42 svc:/milestone/patching:default
online         15:54:38 svc:/milestone/name-services:default
online         15:54:49 svc:/milestone/devices:default
online         15:54:50 svc:/milestone/network:default
online         15:54:50 svc:/milestone/single-user:default
online         15:55:00 svc:/milestone/sysconfig:default
online         15:55:34 svc:/milestone/multi-user:default
online         15:55:51 svc:/milestone/multi-user-server:default

Time to open the service’s manifest file and edit it. And here you have two options:

  • Either a milestone will depend upon your service (the first example);
  • Or make your service dependent on a milestone (the latter one);
 
<dependent
    name='ssh_multi-user-server'
    grouping='optional_all'
    restart_on='none'>
    <service_fmri value='svc:/milestone/multi-user-server' />
</dependent>

<dependency name='network'
    grouping='require_all'
    restart_on='error'
    type='service'>
    <service_fmri value='svc:/milestone/network:default'/>
</dependency>

Now disable, delete, import and enable the service once again:

svcadmin disable service_name
svccfg delete service_name
svccfg import service_name.xml
svcadmin enable service_name

At this point you could safely reboot the system.