Go to main content

Managing System Services in Oracle® Solaris 11.4

Exit Print View

Updated: February 2022
 
 

Showing Service Dependencies

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

image:Figure shows examples of some dependency relationships between services and service instances

Dependency Groupings

Each dependency is assigned to one of the following groupings. The grouping defines how dependencies in that grouping are satisfied.

require_all

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.

require_any

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.

optional_all

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.

exclude_all

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.

Listing Instances That a Service Depends On

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         13:49:26        svc:/milestone/network:default
online         13:49:58        svc:/system/filesystem/autofs:default
online         13:49:58        svc:/system/filesystem/local: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 Showing Whether a Service Will Automatically Restart 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      true
state        online
next_state   none
state_time   July  8, 2020 at  3:51:34 PM PDT
logfile      /var/svc/log/application-pkg-system-repository:default.log
restarter    svc:/system/svc/restarter:default
contract_id  181
manifest     /lib/svc/manifest/application/pkg/pkg-system-repository.xml
dependency   optional_all/error svc:/system/filesystem/autofs:default (online)
dependency   require_all/none svc:/system/filesystem/local:default (online)
dependency   require_all/error svc:/milestone/network: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
autofs/entities fmri svc:/system/filesystem/autofs:default
autofs/grouping astring optional_all
autofs/restart_on astring error
autofs/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
network/entities fmri svc:/milestone/network:default
network/grouping astring require_all
network/restart_on astring error
network/type astring service

Listing Instances That Depend on a 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
disabled       13:48:46        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.

$ svcs -l zones-proxyd
fmri         svc:/application/pkg/zones-proxyd:default
name         Zones Proxy Daemon
enabled      true
state        online
next_state   none
state_time   July  8, 2020 at  4:13:02 PM PDT
logfile      /var/svc/log/application-pkg-zones-proxyd:default.log
restarter    svc:/system/svc/restarter:default
contract_id  182
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/none svc:/application/pkg/system-repository (online)

This output also shows that the zones-proxyd service will be restarted if the milestone/network service stops due to error.

Showing Whether a Service Will Automatically Restart

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.

Table 1  Automatically Restarting a Service After a Dependency Stop
require_all, require_any, or optional_all Dependency
Stop or Refresh Event
restart_on=
none
restart_on=
error
restart_on=
restart
restart_on=
refresh
Stop due to error
No restart
Restart
No restart
Restart
Other stop
No restart
No restart
No restart
Restart
Refresh
No restart
No restart
Restart
Restart

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.

$ svcprop -p restart_on -g dependency system-repository
autofs/restart_on astring error
filesystem-local/restart_on astring none
network/restart_on astring error