Section Navigation

Guardian Process

Brief Description

The InterBase guardian process monitors the uptime of the InterBase server.

Purpose

This process will help ensure that the server will continue to run until it is manually shut down by a system administrator.

Feature Description

This feature will operate as an invisible process. The user will normally not interact with it. On Unix, the ibmgr will start this process.

This feature on Unix supports two command line options:

`-f`	startup forever
`-o`	startup onetime only

If the process is started with the -f flag set the InterBase server will be restarted by this process.

These parameters can be set using the regcfg utility on NT.

On Windows platforms, the guardian will run as a service or an application on Windows NT and only as an application on Windows 95.

When running as an application, the user will see a guardian icon in the Windows 95 task tray. The user will perform all interactions through this icon. These interactions include:

Viewing the InterBase server properties
Shutting down the sever Modifying the startup options for the guardian or the server

When the guardian runs as a service, there is no visual indication (as is the current functionality) that either the guardian or the server is running. To interact with the server, the user needs to run the InterBase Server Manager (ibmgr32.exe) from a Windows Workstation or use the Windows NT Services Manager to shutdown the guardian.

Functional Changes

This is a new feature which will not change the functionality of the existing product.

This process can be started automatically by including in the rc.local file on Unix platforms. The process on starting will check if it was started by user ‘interbmachine_name> on the same lines as isc_init1.<ase (interbas on some platforms), root. It will terminate if it wasn’t. It further tries on Unix to get an exclusive lock on a file, the process exits if it fails to get the lock. On Windows we check for the window of the guardian if the process finds a previous occurance it exits. This ensures that only one instance of the guardian will run. The lock filename on Unix will be isc_guard.<machine_name>)

The main task of the guardian is to fork the super_server and then wait for its exit. On receiving the exit status, it checks if this was a normal shutdown by testing the exit value against a set value. On UNIX it also checks to see if super_server stopped providing a core file.

If gds_super_server has stopped without it being shutdown by the IBMGR tool and the –f option was set, the super_server will be restarted. Otherwise, if it was a regular shutdown, the guardian process will exit (the –o parameter was issued).

Future means of starting the guardian are to be through the inetd.conf so that remote machines could start the guardian process as well.

Implementation

Affected modules:

Since this is a new feature, it will consist of new modules to the codebase. Currently the only new module is: utilitiesguard.c on Unix. On Windows a new component has been added called "iscguard" and the process is called iscguard as we can see that we will need this process to watch over other related servers as well (eg. InterServer).

Proposed Code changes:

This work is completed on the UNIX platforms. The code changes have been put into guard.c. On the Windows platform, we will need to make additional modules. This may require a new component in the source tree,

Psuedo code:

if (command_line_parameters==forever || onetime)
if (user_id=="interbase" || "interbase" || "root")
if (exclusive_lock_file==SUCCESS)
{
open (InterBase_log_file)
write_to_log ("Starting super_server") start_server:
fork (gds_super_server) || CreateProcess (gds_super_server)
wait for server to exit || WaitForSingleObject
if (server_exit==invalid || core || GPF)
{
write_to_log ("Invalid server exit")
if (command_line_parameter==forever)
goto start_server else
{
unlock (exclusive_lock_file)
exit } } }
else
{
open (InterBase_log_file)
write_to_log ("super server already running")
exit } else
{
message ("Invalid User")
exit } else
{
message ("invalid arguments")
exit }

On Windows platforms, the server will need an additional startup flag (-g) that will be passed to it when it is started via the guardian. This flag will prevent the server from displaying its icon. All of the functionality will be accessible via the guardian property sheet and menu

On the Windows platform, all of the guardian log information is written to the InterBase log as well as to the Windows 95 property sheet and to the Windows NT Event Log. The majority of the information written to either of these two places consist of server stops and starts.

Testing

The guardian should be tested as if it were the server. This process should be used to run the server. The tests should be run against both servers that have been started standalone and against servers started via the guardian. Also, on Windows, the guardian should be tested as both an application and a service on Windows NT, and as an application on Windows 95. Integration

Migration

Customers should always start the guardian. This will then start the server. All of the server’s features are surfaced via this process. In the past (on Windows), users would start the server before attempting to connect to any database.

Sign In