IBM® Security Verify Directory Integrator as Linux/UNIX Service

Deployment methods

On Linux and UNIX platforms, there are two different ways of ensuring that certain system jobs or 'daemons' start and stop at respectively system initiation and system termination:

1. Using a script in /etc/init.d containing the logic to start and stop the daemons you are interested in. This script you then (hard)link to scripts in /etc/rc3.d: their names beginning with SXX... and KXX... - the XX being a numeral which causing the files to show up in the right sequence in the /etc/rc3.d directory. The scripts starting with S are called when the system reaches run phase 3 at system startup, and the scripts starting with K are called when the system terminates.
2. By editing the /etc/inittab file.

The latter process is what we describe here. Some of the information presented could be used to construct scripts using the first deployment method.

Tailoring /etc/inittab

In order to start up IBM® Security Verify Directory Integrator daemon processes when the UNIX/Linux OS starts appropriate entries must be added to the /etc/inittab file. The registering of IBM® Security Verify Directory Integrator as a windows service on Windows translates to adding a line of text to the /etc/inittab file on UNIX/Linux. The un-installation of the IBM® Security Verify Directory Integrator windows service on Windows translates to removing the corresponding entries from the /etc/inittab file. For each IBM® Security Verify Directory Integrator daemon process that needs to be started on system startup one line of text must be added to the /etc/inittab file. The format and meaning of the entries in this file is described below. Each entry in the /etc/inittab file has the following format:

Identifier:RunLevel:Action:Command

A description of each of these fields is as follows:

• The Identifier field is a string (at least a single character in length) that uniquely identifies an object. This string is used to uniquely identify the corresponding command.

• The RunLevel field is the run-level in which this entry can be processed. Run-levels effectively correspond to a configuration of processes in the system. Each process started by the init command is assigned one or more run-levels in which it can exist. A run-level is represented by the numbers 0 through N, where N is a positive integer different for the different UNIX/Linux operating Systems (for example on some AIX® computers N is 9, on RedHat Linux N is 6, and so on.). If the OS is running in run-level 3, for example, then only processes specified for run-level 3 are started.

  The RunLevel field can define multiple run-levels for a process by selecting more than one run-level in any combination from 0 through N. For example, if IBM® Security Verify Directory Integratorneeds to run in run-level 3 and 6, then the run-level must be specified as "36". If no run-level is specified, the process is assumed to be valid at all run-levels.

  It is recommended that no run-level numbers are specified, unless the specific IBM® Security Verify Directory Integrator solution specifically needs to.

• The Action field is a value from a set of predefined actions which tells the init command how to treat the process specified in the Command field. There are many actions recognized by the init command, but for running the IBM® Security Verify Directory Integrator server as a daemon process it is recommended that the once action be used. The semantics of the once action are:

  When the init command enters a run-level that matches the entry's run level, start the process, and do not wait for its termination. When it dies, do not restart the process. When the system enters a new run level, and the process is still running from a previous run level change, the program not be restarted. All subsequent reads of the*/etc/inittab* file while the init command is in the same run level cause the init command to ignore this entry.

• The Command field specifies the shell command to run.

Here are three example IBM® Security Verify Directory Integrator-related entries in /etc/inittab:

tdi1::once:/opt/IBM/TDI711_1/ibmdisrv -c "/opt/IBM/TDI711_1/myconfigs/rs1.xml" -r "testAL1"
tdi2::once:/opt/IBM/TDI711_2/ibmdisrv -c "/opt/IBM/TDI711_2/myconfigs/rs2.xml" -r "testAL2"
tdi3::once:/opt/IBM/TDI711_3/ibmdisrv -c "/opt/IBM/TDI711_3/myconfigs/rs3.xml" -r "testAL3"

This example starts three IBM® Security Verify Directory Integrator server instances which are installed in different folders.

Note: There are some differences in the different UNIX/Linux operating systems for system startup. That is why the information provided here covers the main issues of starting IBM® Security Verify Directory Integrator on a UNIX/Linux system and does not refer to any specific UNIX/Linux system.

Graceful shutdown

On UNIX systems we always perform a graceful shutdown of the service. This is achieved by a shutdown hook added to the Java™ Runtime Environment. That way, when the server is stopped with either SIGINT or SIGTERM signals, this hook is executed and the server is gracefully terminated.

Another advantage of this approach is that this hook will be invoked on all platforms when the server is stopped by pressing CTRL+C in its console window.

Note: You can also specify an external program to be started from within the JVM shutdown Hook. This external program is configured using an optional property in the

global.properties or

solution.properties file: jvm.shutdown.hook. If configured the external program will be started right after the server has shut down gracefully.