Dependency relationships govern service instance state transitions. See Service Dependencies for a high-level description of dependencies. See Developing System Services in Oracle Solaris 11.4 for detailed descriptions and how to specify different kinds of dependencies.
In the following figure, the svc1:default, svc2:default, and svc3:default service instances do not require any other services or any files or other resources to start. These instances can start in parallel, execute their start methods, and move to the online state without waiting on any other resources. The svc4:default instance cannot execute its start method until the svc2:default instance is online. The svc5:inst1 instance needs both svc2:default resources and svc4:default resources. The dependency that svc5:inst1 has on svc4:default is an optional dependency and is satisfied if svc4:default is in one of the following states: enabled and online, disabled, or not present. The svc5:inst1 instance must wait until svc2:default is online, and if svc4:default is present and enabled, svc5:inst1 must also wait until svc4:default is online. If svc4:default is present and disabled or is not present, svc5:inst1 does not need to wait for svc4:default.
Figure 2 Service Dependency Relationships
Each dependency is assigned to one of the following groupings. The grouping defines how dependencies in that grouping are satisfied.
This dependency is satisfied when both of the following conditions are met:
All of the service dependencies in this grouping are running, either online or degraded.
All of the file dependencies in this grouping are present.
This dependency is satisfied when either of the following conditions is met:
At least one of the service dependencies in this grouping is running, either online or degraded.
At least one of the file dependencies in this grouping is present.
This dependency is satisfied when all of the service dependencies in this group meet either of the following conditions:
The service is running, either online or degraded.
The service requires administrative action to run. The service is not present, is incomplete, is disabled, is in maintenance, or is offline waiting for dependencies that require administrative action to start.
File dependencies in this group can be present or not present.
This dependency is not satisfied if the service instance is in transition and does not require administrative intervention to start. In this case, the dependent service waits for this dependency to start or waits for the determination that the dependency cannot start without administrative action.
This dependency is satisfied when both of the following conditions are met:
All of the service dependencies in this grouping are disabled, in maintenance, or not present.
All of the file dependencies in this grouping are not present.
The svcs -d command lists the service instances that a given service depends on.
This example shows the service instances that the system-repository service depends on:
$ svcs -d system-repository STATE STIME FMRI online Sep_09 svc:/milestone/network:default online Sep_09 svc:/system/filesystem/local:default online Sep_09 svc:/system/filesystem/autofs:default
The svcs -l command also lists the services that a given service depends on. In addition to the name and state of the dependency, the -l option output shows the type, or grouping, of the dependency and the value of the restart_on property of the dependency. In this example, two of the dependencies are required and one is optional. See Dependency Groupings for descriptions of how dependencies in these groupings affect the dependent service. See Dependency Groupings for descriptions of how different values of the restart_on property of the dependency affect the dependent service.
$ svcs -l system-repository fmri svc:/application/pkg/system-repository:default name IPS System Repository enabled false state disabled next_state none state_time Mon Sep 09 18:42:28 2013 restarter svc:/system/svc/restarter:default manifest /lib/svc/manifest/application/pkg/pkg-system-repository.xml dependency require_all/error svc:/milestone/network:default (online) dependency require_all/none svc:/system/filesystem/local:default (online) dependency optional_all/error svc:/system/filesystem/autofs:default (online)
You can also use the svcprop command to list these dependencies. This form shows the grouping and restart_on values of the dependency on separate lines, and does not show the state of the dependency.
$ svcprop -g dependency system-repository:default network/entities fmri svc:/milestone/network:default network/grouping astring require_all network/restart_on astring error network/type astring service filesystem-local/entities fmri svc:/system/filesystem/local:default filesystem-local/grouping astring require_all filesystem-local/restart_on astring none filesystem-local/type astring service autofs/entities fmri svc:/system/filesystem/autofs:default autofs/grouping astring optional_all autofs/restart_on astring error autofs/type astring service
The svcs -D command lists the service instances that depend on a given service.
This example shows the service instances that depend on the system-repository service:
$ svcs -D system-repository STATE STIME FMRI online 16:39:30 svc:/application/pkg/zones-proxyd:default
The following command confirms that zones-proxyd depends on system-repository.
$ svcs -do svc,desc zones-proxyd SVC DESC application/pkg/system-repository IPS System Repository system/filesystem/minimal minimal file system mounts milestone/network Network milestone
The following command shows more information about how zones-proxyd depends on system-repository. The last line of this output shows that the zones-proxyd service requires the system-repository service to be running and shows that system-repository is currently running. This output also shows that the zones-proxyd service will be restarted if the system-repository service is refreshed.
$ svcs -l zones-proxyd fmri svc:/application/pkg/zones-proxyd:defaulr name Zones Proxy Daemon enabled true state online next_state none state_time January 6, 2014 04:39:30 PM PST restarter svc:/system/svc/restarter:default manifest /lib/svc/manifest/application/pkg/zoneproxyd.xml dependency require_any/none svc:/system/filesystem/minimal (online) dependency require_any/error svc:/milestone/network (online) dependency require_all/restart svc:/application/pkg/system-repository (online)
A running service can be configured to restart when one of its dependencies is stopped or refreshed. If dependencies of a running service (online or degraded state) are not satisfied, the service transitions to the offline state. If a service restarts after a dependency stop or refresh, dependencies might again be satisfied and the dependent service transitioned back to a running state.
The following factors determine whether a service is restarted after a require_all, require_any, or optional_all dependency is stopped or refreshed:
Whether the dependency was stopped or refreshed. If stopped, whether the dependency was stopped because of an error such as a hardware error or a core dump or for some other reason such as an administrative action.
The value of the restart_on attribute of the dependency. Possible values are none, error, restart, and refresh.
As shown in the following table, if the value of the restart_on attribute of the dependency is none, the dependent service is not restarted when the dependency is stopped or refreshed. If the value of the restart_on attribute of the dependency is refresh, the dependent service is always restarted when the dependency is stopped or refreshed. If the value of restart_on is error, the dependent service is only restarted if the dependency stopped because of an error. If the value of restart_on is restart, the dependent service is only restarted if the dependency was refreshed.
Listing Instances That a Service Depends On shows that the system-repository service has two require_all dependencies and one optional_all dependency. The following command shows that the system-repository service will be restarted if the milestone/network service or the system/filesystem/autofs service stops due to an error but not if they stop for any other reason or are refreshed. The system-repository service will not be restarted if the system/filesystem/local service is refreshed or stopped for any reason.
$ svccfg -s system-repository:default listprop -o propname,propval '*restart_on' network/restart_on astring error filesystem-local/restart_on astring none autofs/restart_on astring error