It is not necessary to run the alarms service in a separate domain, though depending on the individual system configuration it may still be advisable not to embed the service in a domain already burdened with higher memory requirements. To handle alarms under a relatively high load (100Hz on the server end) requires only about 2% more of the cpu, but about 75-100 MiB of additional space. In order to capture any alarms from other domains at startup, it is also necessary to arrange for the alarm service to start before the other doors and pools.

While there is nothing strictly preventing the use of multiple alarms services, under normal circumstances this should not be necessary. The only constraint on the service set-up has to do with the storage option. Unlike for the RDBMS (relational database) back-end, there is currently no option for remote access of the XML file. Since the alarms storage needs to be written to by the alarms service but also read by the httpd service, it is thus necessary for that file to exist on a shared or mounted partition visible to both. Obviously, no such requirement exists for the RDBMS option.

Add the alarms service to a domain in the layout file:

    [alarmsDomain]
    [alarmsDomain/alarms]
    alarms.db.type=rdbms
    ...
    

OR

    [someotherDomain]
    [someotherDomain/alarms]
    alarms.db.type=rdbms
    [someotherDomain/someotherservice]
    ...
    

Note that the storage type setting alarms.db.type must be defined either in the layout or /etc/dcache/dcache.conf file because its default value is off; this can be set to either xml, or rdbms. In the latter case, the standard set of properties can be used to configure the connection url, db user, and so forth. Before using the rdbms option for the first time, be sure to run:

        createdb -U alarms.db.user alarms
    

to create the database; as usual, the actual schema will be initialized automatically when the service is started.

For the XML option, the storage file is usually found in the shared directory for alarms (corresponding to alarms.dir); the usual path is /var/lib/dcache/store.xml, but the location can be changed by setting alarms.db.xml.path. This will automatically be propagated to alarms.db.url and consequently to httpd.alarms.db.url if the two domains are on the same host; if they are not (and share this file path via a mount, for instance), be sure to set the httpd property in the layout or /etc/dcache/dcache.conf on the httpd host to correspond to the new alarms.db.url.

As a rule of thumb, the choice between XML and RDBMS is dictated by two factors: whether it is feasible to share the XML file between the two services as noted, and how much history is to be preserved. While the XML option is more lightweight and easier to configure, it is limited by performance, experiencing considerable read and write slowdown as the file fills (beyond 1000 entries or so). If you do not need to maintain records of alarms (and either manually delete alarms which have been serviced, or use the built-in cleanup feature – see below), then this option should be sufficient. Otherwise, the extra steps of installing postgreSQL on the appropriate node and creating the alarms database (as above) may be worth the effort.

        dcache.log.level.remote=off
        dcache.log.server.host=localhost
        dcache.log.server.port=9867
    

     #  ---- Host on which this service is running
     alarms.net.host=${dcache.log.server.host}
     #  ---- TCP port the alarms service listens on
     alarms.net.port=${dcache.log.server.port}
    

            dcache.log.server.host=<head-node>
       

The Alarms Web Page is an admin page and thus requires authentication. You must enable HTTPS and set an admin gid (0 by default):

    [httpdDomain]
        httpd.enable.authn=true
        httpd.authz.admin-gid=<1234>
    [httpdDomain/httpd]
    

When Refresh is clicked, any updates to Closed and Notes are first saved, then any Deletes are processed, and finally, the table is repopulated using the current query filter. The entire form is set to auto-refresh every 60 seconds.