If a new package requires a custom configured instance of a service, that package can deliver just the custom instance without modifying any other service.
Using multiple manifests to define a service enables you to deliver service instances only as needed and without modifying the parent service. For example, if instance I of service S is only needed by tool T, then tool T can deliver instance I without redelivering service S. Then if tool T is not installed on the system, instance I also is not installed, even if service S is installed. Similarly, if tool T is uninstalled, instance I is uninstalled, leaving service S still installed and unmodified. Specify service S in one manifest and instance I in a separate manifest. Deliver the service S manifest in one package, and deliver the instance I manifest in the tool T package. The tool T package has a dependency on the package that delivers service S.
If you use multiple manifests to specify a single service, use the following service manifest design:
In one manifest, include the service definition, template data, and a default instance.
In each manifest that defines additional instances of the service, include the following:
Specify the same service_bundle element as in the manifest that contains the service definition, and then add the include attribute. The value of the include attribute is the full file name of the manifest that contains the service definition.
Specify the same service element as in the manifest that contains the service definition. The value of the name attribute in the service element is exactly the same as in the manifest that contains the service definition.
Do not deliver the same service or instance in multiple manifests, When this type of conflict is detected, SMF cannot determine which definitions to use, and the instance is placed in the maintenance state.
An example of a service that is delivered in multiple manifests is the svc:/system/console-login service. The console-login service includes the following instances and manifests:
The manifest /lib/svc/manifest/system/console-login.xml delivers the service definition, the templates, and the default instance.
The manifest /lib/svc/manifest/system/console-login-terma.xml delivers the terma instance of the console-login service.
The manifest /lib/svc/manifest/system/console-login-termb.xml delivers the termb instance of the console-login service.
The manifest /lib/svc/manifest/system/console-login-vts.xml delivers the vts instances of the console-login service.
The manifest that contains the service definition, /lib/svc/manifest/system/console-login.xml, contains the following lines:
<service_bundle type="manifest" name="SUNWcs:console">
<service
name="system/console-login"
type="service"
version="1">
<instance name='default' enabled='true'>
</instance>
The manifest that defines additional instances vt2, vt3, vt4, vt5, and vt6, /lib/svc/manifest/system/console-login-vts.xml, contains the following lines:
<service_bundle type="manifest" name="SUNWcs:console"
include="/lib/svc/manifest/system/console-login.xml">
<service
name="system/console-login"
type="service"
version="1">
<instance name='vt2' enabled='true'>
<dependency
name='system-console'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/system/console-login:default' />
</dependency>
</instance>
The definitions of instances vt3, vt4, vt5, and vt6 contain the same dependency on console-login:default as shown for the vt2 instance.
The svcs command output displays the dependency relationships, as shown in the following examples:
$ svcs 'svc:/system/console-login:vt*' STATE STIME FMRI online Dec_04 svc:/system/console-login:vt3 online Dec_04 svc:/system/console-login:vt5 online Dec_04 svc:/system/console-login:vt2 online Dec_04 svc:/system/console-login:vt4 online Dec_04 svc:/system/console-login:vt6 $ svcs -D console-login:default STATE STIME FMRI online Dec_04 svc:/system/vtdaemon:default online Dec_04 svc:/system/console-login:vt3 online Dec_04 svc:/system/console-login:vt5 online Dec_04 svc:/system/console-login:vt2 online Dec_04 svc:/system/console-login:vt4 online Dec_04 svc:/system/console-login:vt6 online Dec_04 svc:/system/console-reset:default $ svcs -d 'svc:/system/console-login:vt*' STATE STIME FMRI ... online Dec_04 svc:/system/console-login:default online Dec_04 svc:/system/vtdaemon:default
The default, terma, and termb instances are delivered by the system/core-os package. The vts instances are delivered by the system/virtual-console package. The system/virtual-console package contains a require dependency on the system/core-os package to ensure that the console-login:default instance exists.
If a service has only one instance, best practice is to use a single manifest to specify the service: Define the one instance in the manifest that contains the service definition.