the service manager

The service-manager rules the underground, wich means, it watches the services and decides, which service needs to get startet or which one should die. The services are "pure"-java, but as java does not offer any possibility to determine the id of a running process, the service-manager is wrapped by a shellscript.

The services managed by the service-manager are simple jar-files with corresponding database entry. To enable the service-manger to start the services using the configured userid, it should be run as privileged process (as root process).

New: when a service has a pre-start-script defined, the ServiceManager checks, whether that script is valid and executable. If so, the script will be executed and the ServiceManager waits the defined sleeptime, before it starts the service. If a triggerfile is defined, the service will be started only if the triggerfile exists.

Same is true for the shutting down of a service. If a post-end-script is defined, the ServiceManager waits the post-end-time, before it executes the script.

Intention of the scripts is to support the wakeup of a remote machine before a service may need it. Therefor it is possible, to define a triggerfile. The triggerfile could be a file from the remote machine. This way it is possible for the ServiceManager to validate the successful mount of the remote drive.

As the scripts will be executed using the same userid that is defined for the service, the remote drive should have the option "user" in /etc/fstab. Otherwise an error may occure, that the drive may not be mounted.

The scripts are called with 2 parameters:

1. start/stop - used to identify whether the script runs before or after the service
2. absolute path of the triggerfile - this way, a script may handle various triggerfiles

If the pre-start-script creates the triggerfile, the post-end-script should remove it.

See also applications / dower