Solaris SMF

As of version openFT V12.1B, the platform Solaris is only supported on request.

SMF (Service Management Facility) can be used to describe in detail the dependencies of a service on other services, files or milestones (correspond to the earlier run levels), as well as instances of the service, in a manifest.

This results, for example, in significantly shorter start times because many services can be started in parallel and the start sequence can be optimized thanks to the description of the dependencies.

The various services in the system are administered via a uniform interface. This ensures that operation is more robust, i.e., for example, if a service is terminated unexpectedly (e.g. due to an unintentional kill -9) then it is restarted automatically.

Operation with SMF differs from operation without SMF as follows:

• The start scripts /etc/init.d/openFT and /var/openFT/instance/etcinit/openFTinst are not installed with Solaris SMF. ftalarm is activated via SMF, see section “Solaris SMF”.

• There is no automatic check of the profile files and no automatic clean-up of the log files.

• The dependency on CMX is not defined since CMX is not involved in the SMF installation procedure. If openFT is used with CMX then diagnostic records may be generated for openFT during booting. These are created during the period before CMX becomes available. The reason is that all the SMF milestones are first activated and that the RC scripts are then started. This means that CMX is not started until after openFT. In openFT V12.0 or higher, it is no longer essential for CMX to be present when RFC1006 is used.

The following commands have been adapted for use with the SMF procedure to ensure that they function in the usual way:

• ftstart takes over environment variables and starts openFT via SMF. The SMF command (without transfer of environment variables) is as follows:

  svcadm enable openFT:instance

  The familiar openFT messages are not displayed for svcadm.

• ftstop terminates openFT via SMF. The SMF command is as follows:

  svcadm disable openFT:instance

  The familiar openFT messages are not displayed for svcadm.

• In addition to the instance, ftcrei also generates a manifest and enters this in SMF.

• ftdeli deletes the instance and removes the corresponding manifest from SMF.

For the setting of protection bits using SMF, please refer to section “Setting the protection bit for newly created files (Unix systems)”.

Characteristics in single-user mode

In single-user mode the openFT instances that are enabled in the SMF are not monitored by the SMF, i.e. the openFT user can start or stop the openFT instance at will with the commands ftstart and ftstop. Only the system administrator (root) can use the SMF commands to define whether the openFT instance is started (enabled) or not started (disabled), see above.

When booting the system the settings defined by the system administrator apply.

When switching to multi-user mode ftstart and ftstop are also used to execute the corresponding svcadm command.

Activating ftalarm automatically

As described below, ftalarm can be started and stopped manually via the command line. On Solaris systems, ftalarm can also be administered via SMF. The ftalarm manifest that is required for this is automatically generated and installed for each instance.

Mixed operation (manual operation and control via SMF) is not recommended because SMF is not informed of changes. As far as SMF is concerned, ftalarm is a so-called transient service, i.e. there is no process to be monitored.

Example

ftalarm can be started for the instance inst001 using the following commands:

# svcadm enable ftalarm:inst001

# svcadm disable ftalarm:inst001

Creating the instance inst001:

# svcadm enable ftalarm:inst001

# svcadm disable ftalarm:inst001

Creating the instance inst001:

# ftcrei 001 -addr=inst001
# svcs *:inst001
STATE          STIME    FMRI
disabled       16:31:50 svc:/application/openFT:inst001
disabled       16:31:51 svc:/application/ftalarm:inst001
# svcadm enable ftalarm:inst001
# svcs *:inst001
STATE          STIME    FMRI
disabled       16:31:50 svc:/application/openFT:inst001
online         16:32:14 svc:/application/ftalarm:inst001
#. ftseti inst001
# ftstart
ftstart: openFT 12.1A00 starting. Protocols: openFT,FTAM,ADM

# svcs *:inst001
STATE          STIME    FMRI
online         16:32:37 svc:/application/openFT:inst001
online         16:32:38 svc:/application/ftalarm:inst001

The ftalarm cronjob for the instance inst001 is not started unless the instance inst001 has also been started. Similarly, the instance ftalarm is terminated when the instance inst001 is terminated with ftstop.

The number of errored FTAC sets can be set using the ftalarm instance's SMF environment variable ERRORS, e.g. as follows for the instance inst001:

1. Terminate ftalarm for the instance inst001 using the command:

   # svcadm disable ftalarm:inst001

2. Change the number of errors for monitoring (e.g. to 42) using the command:

   # svccfg -s ftalarm:inst001 setenv -i ERRORS 42

3. Take over the settings using the following command:

   # svcadm refresh ftalarm:inst001

4. Start ftalarm for the instance inst001 using the command:

   # svcadm enable ftalarm:inst001

5. You can display the settings with:

   # svcprop -t -p method_context/environment ftalarm:inst001

   method_context/environment astring OPENFTINSTANCE=inst001 ERRORS=42