Note: This web site is only kept up to date for OSG Software 1.2 (VDT 2.0.0). If you are looking for information for the most recent release, the RPM-based OSG Software 3.0, please see the OSG documentation web site

Service Management Subsystem Notes

Use Case List

The service management subsystem will support the use cases listed below. The use cases use the words enable and disable to mean very specific things:

To enable a service means to install it at the system-wide level and, for RC services, to start the service. An enabled service works normally upon reboot without manual intervention. For example, to enable an RC service, its init script is copied to /etc/init.d (or equivalent) and started; likewise, to enable a cron service, it is added to a crontab.
To disable a service means to remove it from the system-wide level and, for RC services, to stop the service. A disabled service does not run automatically upon reboot. For example, to disable an RC service, its init script is removed from /etc/init.d (or equivalent) and stopped; likewise, to disable a cron service, it is removed from its crontab.
desired state
The desired state of a service determines whether the service should be enabled when the VDT is running.

Use cases:

Service Management Scripts

The service management subsystem will contain two scripts:

Used to register a service, change a service’s registration information, and set the desired state of a service.
Used to enable and disable services.



--name NAME
The name and unique identifier of the service. Required.
--type TYPE
The type of the service. Valid values are init, inetd, and cron. Required for a new service.
Set the desired state of the service to enable. Mutually exclusive with --disable.
Set the desired state of the service to disable. Mutually exclusive with --enable.
--init-script PATH
The path to the init script. Required for a new init service.
--port PORT
The port on which the service runs. Required for a new inetd service.
--protocol PROTOCOL
The protocol on which the service runs. Required for a new inetd service.
--inetd-command COMMAND
The complete command and arguments to run an inetd service. Required for a new inetd service.
--cron-time TIME-SPEC
The time specification for a cron job. Required for a new cron service.
--cron-command COMMAND
The complete command (with arguments) for a cron job. Required for a new cron service.
Removes the service from the system state file. All other options are ignored.

For an existing service, it is possible to include just a --name and --enable/--disable flag to set the desired state of the service.



Enable services that should be enabled.
Disable all services.
List of service names to consider. Omit to apply to all known services.

One and only one of --on and --off must be specified.

State File Format

The service management state file will be located at


There will be one line per service/type combination, where the service is simply the name of the service and the type is a string identifying the method of running the service.

The format of a line is

NAME <tab> TYPE <tab> ENABLE <tab> DETAILS
where the components are defined as follows:

The name of the service
The type of the service: init, inetd, or cron
The desired state of the service: enable or disable
Type-specific data for the service, separated by tabs

DETAILS fields are as follows:

crontime spec (crontab format), command and arguments
inetdport, protocol (tcp or udp), command and arguments
initpath to init script

Detailed Proposal for Service Management


This script is used to install services on a machine when the VDT is deployed. It can install tasks into inetd/xinetd, init.d, and crontab, as well as modify the 'services' definition file. It has mechanisms to figure out whether the system is running inetd or xinetd. When the script is called to install a task into a subsystem, it first removes any trace of it in the target subsystem, then writes if the install flag is enabled, it then proceeds to add in the information as appropriate.

The script does not keep a record of what items it has installed or uninstalled. I propose that we keep a logfile of what is installed by the system and whether it is currently enabled or not. This will basically serve as a record of what items that this VDT installation is responsible for; vdt-install-service should be able to remove and add back the appropriate addition to the subsystems strictly based on the contents of the file. We will also need to provide a way for other scripts to easily list out all the packages from this file.

We also do not currently have any mechanism for allowing us to dictate the boot order of our services (this only matters for init.d scripts). From what I can tell, all our services are installed to start and stop at the same init level (99) and at all run levels; I can only assume that scripts are executed in alphabetical order within the run level. I am not sure if it is possible to change this to give us a finer grain control. One possible solution would to make our our 'vdt-init' wrapper script that would in turn call the appropriate init script, allowing us to control the boot order.

If we wanted to go this route, we will need to provide a switch to this script that would allow one to specify which order level that the service needed to be started at. The default would place the service in the last 'bucket' of when services to get started.

To make it more clear what kind of installation (cron/init/inetd) each configure script for a package does each configure script does, we also might want to come up with a nice wrapper class or simple hashtable that can be declared at the top of each configure script. This would make things more uniform and easier to follow rather than embedding the calls to vdt-install-service deep inside of the code.


I decided that the name 'vdt-enable' was more indicative to what we are trying to accomplish. By default, the script will install a package into the appropriate subsystem (as defined in its configure script) and also prop up all the services that it knows about. The later functionality can be disabled by passing a '--nostartup' flag.

This script basically invokes vdt-install-service for each package that was installed that requires to be instantiated by a subsystem. Then it will attempt to start the package's daemons by invoking the init scripts.

It is not clear to me whether this script becomes the new 'frontend' for users to start and stop daemons in the VDT. That is, instead of calling the 'post-install/daemon' scripts directly, they can pass a flag to start a particular daemon ('vdt-enable apache').

The question that really matters whether we want to let a package's daemon execute on a system that we know is not properly configured as it should be. It is not clear to me at this time whether we want a more rigid control over our system-wide environment.


This script is used to essentially disable a VDT installation from running. There are two parts of this operation: (1) we must shutdown all services that we have started, (2) we must disable these services from starting again when the system is rebooted. This is basically a reversal of the operations done in vdt-enable.

When vdt-disable is called, it runs reads the list of packages that are installed and first calls the init scripts to stop the daemons. Next vdt-disable calls 'vdt-install-service --remove' in the reverse order of how things were originally installed. The logfile is marked that the package has been disabled.

Use Cases

These examples assume that the VDT is installed as root. I believe that non-root installations would be similar, except that the VDT installation scripts would be unable to add all the information that needed for packages to certain subsystems (init/inetd).

  1. User installs VDT, then invokes vdt-disable
    • At installation time, each configure script calls vdt-install-service as needed
    • vdt-enable is not called
    • When vdt-disable is executed, it stops the daemons the best it can and then removes the services
  2. User installs VDT in two different locations, then disables them one at a time
    • The user installs the exact same set of packages in two different locations on a machine
    • The first installation is disabled
    • The second installation is disabled, but the vdt-install-service can detect that the subsystem information it needed to remove was already gone
  3. User installs VDT in two different locations, disables the first, re-enables the second
    • The user installs the exact same set of packages in two different locations on a machine
    • The first installation is disabled
    • Now the user wants to use the second installation. They must first call vdt-enable so that all the subsystem settings are correct.

Open Issues and Other Random Ideas