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 |
|---|---|
| S | milestone/single-user:default |
| 2 | milestone/multi-user:default |
| 3 | milestone/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.