Configuring NaturalAccess as a Linux Service

Introduction

In contrast to the Microsoft Windows version, the Dialogic® NaturalAccess™ for Linux package does not install ctdaemon into the operating system as a service. It must be started manually, with root privileges. This article describes how to implement a standard Linux boot script that starts ctdaemon during system start-up. After a soft or hard reset, no physical actions are required to bring-up the NaturalAccess software layer, leaving the platform ready to run the hosted telecom applications.

Background

Once a system is powered on, or there is a hard reset, and the OS loader has completed its task, the kernel is running on the platform. The kernel's task is to launch the first (user) process, namely /sbin/init, which, by reading the contents of the /etc/inittab file, determines which services must be brought up and run at a given run level. Since it is not convenient to manage all services using one single file, inittab specifies which directories to search for scripts that start/stop the individual services. For example, developers can view and edit the /etc/rc.sysinit and /etc/rc script files on their system in the /etc directory.

For each of the managed service, there is a single script file, usually located in the directory /etc/init.d/. Each script file implements the corresponding start-up and shutdown procedures of its process. Other functions, such as "status" or "reload", can be included using the /etc/init.d/functions script file.

The /sbin/init process does not actually go through the above mentioned files, but instead uses a set of soft-links, which names the directories, and are ordered sequentially, e.g.:

Where X is the run level. YZ is the launch priority of the service "service_name" at the run level X. K-files are used when a service has to be stopped, S-files when it has to be started. To determine the appropriate run level and launch sequence (with respect to other services), standard lexicographic order applies (limited to the first three letters of the file). Most Linux distribution provide a simple command-line tool, chkconfig, which among other functionalities, populates the directories /etc/init.d/rcX.d with the soft-links pointing to the single service script, in /etc/init.d/.

Procedure

The DIalogic NaturalAccess™ Software for Linux provides a sample file, /etc/init.d/nmsctdaemon, which sets the required environment variables and OS-dependent parameters to correctly start and stop ctdaemon. In order to maintain system files unmodified, it is recommended that developers make their own copy whenever they wish to add new functionalities.

To register ctdaemon as a Linux service, proceed with the following steps.

1. Copy the sample file below into /etc/init.d/myservicectdaemon (or any other valid name), on the local hard drive.

2. Make it executable/read-only for everyone except root.

3. Run chkconfig.

4. Verify that the new service is properly registered:

The run level is automatically configured via chkconfig, which uses the pragma contained in the myservicectdaemon file:

or here

(02 is high shutdown priority)

chkconfig will automatically create the soft-links in the corresponding /etc/rcX.d/ folders:

It is worth noting that a 98 (low) priority and a run level #5 are required, so that ctdaemon is effectively started after the NaturalAccess 'nms_' scripts have loaded the board drivers:

Using this method, a Linux platform can benefit from the auto-start and auto-stop features of ctdaemon, provided the following keywords:

are defined in their configuration files.

Sample Boot Script

A simple boot script was implemented to register NaturalAccess ctdaemon as a Linux service. Once copied in the /etc/init.d/ directory, and the correct soft-links are created in the /etc/rcX.d folders, the Linux boot sequence launches ctdaemon automatically at the run level #5. This method can be used to enable board auto-start on the platform, making it quickly operational to run hosted telecom applications.

The boot sequence described in this support tip applies to SYSV-R4 based systems, which currently cover most UNIX flavours. Though the chkconfig command-line tool is Linux-specific, the paths to service scripts remain unchanged. Therefore, the same method can be used, for example, on Solaris platforms.

Sample Script