SMF service - instances

A SMF service is a set of related daemons and (sh) scripts collectively abstracted as a service abstract object, which may have one or more concrete running instances. It is important to grasp this concept of a SMF service as not necessarily being a mere synonym to a single daemon or scheduled batch job. In fact, there's a whole framework under the hood.

One or more SMF services are deployed in bundles.
Within the service_bundle tag there can be multiple service tags:

...

<service type="service" version="..." 
 name="..." >
  ...
</service >

... 

<service type="service" version="..." 
 name="..." >
  ...
</service >

...

NOTE

With respect to the above service tags, the name attribute is the broadly visible canonical service name. For simple service development, the type attribute should always be service, although restarter and milestone are other possible values (see DTD for further detail). Furthermore, although suggested, despite not clearly stated, it's not supported to have services with the same name but a different version number. With respect to version, it's commonly seen non-negative integers, but "1.0" seems acceptable too.

NOTE

The service name should follow the recommendation of prefixing the service name with one or more categories names in order to better organize and classify the service. The categories are found in /lib/svc/manifest or /var/svc/manifest and means:

application : higher-level software
milestone   : collections of other services
platform    : platform-specifics
system      : system services
device      : device-specifics
network     : network / internet
site        : site specifics

Example: application/apache.

Now things becomes slightly more interesting as it's time to describe each service in the bundle. But before going any further with the XML syntax details, let's clarify one (possibly) subtle point regarding a service and its metadata. An SMF service is "materialized" on a running system by one or more instances of that given service. Although related, fact is, this subtle difference is reflected into metadata which is the important point to understand:

★ Each ("concrete") service instance inherits all the metadata defined on its parent ("abstract") service description, but should define distinguishable overrides as necessary. This means that metadata common to all sibling instances should be factored out up to their common parent service. Each service instance is described within its parent service description. 

When a service is single instance (has only one instance) it's very convenient to name that instance as default because this way one can refer to it just by the service name. If, otherwise, a different name is chosen, then the only way of referring to it is by suffixing its name to the (parent) service name as in service_name:instance_name. Single instances services should be marked so and default ones count with a simplified syntax for greater convenience.

Example:

A default single instance:

...

<service type="service" version="..." 
 name="..." >

  <create_default_instance enabled="..." />
  <single_instance />

  ...

</service >

... 

or

...

<service type="service" version="..." 
 name="..." >

  <instance enabled="..." name="default" />
  <single_instance />  

  ...

</service >

...

A non-default single instance:

...

<service type="service" version="..." 
 name="..." >

  <instance enabled="..." name="..." />
  <single_instance />  

  ...

</service >

...

When a service has multiple instances, where one of them is somehow considered "primary" over the others, then there may be a point in naming that primary instance as default, otherwise, it's probably better to give each instance a different and more meaningful name.

Example:

...

<service type="service" version="..." 
 name="..." >

  <instance enabled="..." name="..." >
    ...
  </instance >

  <instance enabled="..." name="..." >
    ...
  </instance >

  ...

</service >

... 

NOTE

On the above instance description excerpts, the enabled attribute can assume the enabled of disabled values, representing not only the instance initial state, but telling the service restarter (by default svc.startd) it should attempt to maintain service availability.

NOTE

What the single_instance tag actually means is that no more than one instance can be online at any given time. It doest not prevent a service from having multiple instances defined.