Daemons

All ACS services and containers described in the previous chapters can be started and stopped by executing scripts provided by ACS. To execute these scripts directly, the user must be logged in on the host machine, or use the remote-ssh features provided by the ACS command center or the Alma Operator Master Client. Running ACS scripts in this way is still recommended for development and modular testing, but any large scale testing or real operations of the system should start ACS services and containers in a different way, using the ACS daemons.

There are two types of daemons, one for managing ACS services, and one for managing ACS containers. They must be started before ACS, where "ACS" now refers to the services and containers only, excluding the daemons which of course are also part of ACS in terms of software development and packaging. The starting can be done as part of the host machine's boot sequence, or later using some initialization framework outside of ACS. The ACS daemons are implemented as Corba aware application, that are not daemons in the sense of the operating system.

An ACS daemon only manages ACS services / containers on its local host machine, which means that a daemon must be running on every machine that should run ACS services and/or containers. There is at most one instance per daemon type running, handling all ACS instances ($ACS_INSTANCE numbers).

By default an ACS daemon can only be shut down by killing the process, which ensures protection if a privileged user account is used to start the daemon. As of ACS 8.0.0, it is not yet possible to have ACS services or containers started as a different OS user than the one who started the daemon; this feature may have to be added in the future.

The daemons will monitor their services or containers, and will raise alarms and/or restart the service in case of failures.

Services daemon

• A services daemon can start, monitor, and stop one or more of the ACS services.
• Services can be run on different machines, in any combination, e.g. CDB and manager on one machine, the Log service on another, and so on
• The daemons offer two APIs:
  • A "direct" API that lets the client decide what services to start in which order. The client must connect to the daemons on all machines it wants to use. The daemon does not check the order in which services are started, nor illegal attempts to start a singleton service twice.
  • A more sophisticated API that builds up or takes an existing XML based services description, and then processes it. Here the daemon knows about service dependencies and will start services in correct order. The client can connect to the services daemon on an arbitrarily selected machine, and sends the service requests for all machines; the daemon will contact other daemons as needed.
• Internally the services daemon consists of separate processes:
  • One main process that is the contact point for the daemon clients
  • Per type of service it runs one "Imp" process to which it delegates the actual work. For example, if a client requests to run the Corba naming service, the CDB, and 5 different Notify Services on a host machine, then a total of 3 Imps get created.
  • This design makes the daemon more robust, as the Imps can be restarted transparently. It also allows for specialized Imps, e.g. an Imp for running the ACS manager, which is itself written in Java in order to probe the manager's threading situation over JMX calls.
• The services daemon is started with the command acsservicesdaemon. When started with the --unprotected option, the services daemon can be shut down using the command acsservicesdaemonStop. This is mostly useful when using daemons as part of automated tests, that clean up after themselves.

Container daemon

• A container daemon can start and stop any number of containers on its own host.
• In the future it should also monitor containers.
• A container daemon is required to be running if an ACS container is configured in the CDB to be started automatically by the manager (at ACS start, or upon direct request to a component that should run in that container, or upon indirect request by an autostart component configured to run in that container).