The maintenance-services is AURORA-services to do various cleanup- and administration operations for the AURORA-system.
They checks if datasets are about to expire and creates notifications within the given notification-intervals (14 days before, 7 days before 1 day before etc.). They also checks if any dataset have expired and if any are overdue its expiration date without being removed.
Furthermore they clean up and handle notifications that have ended, distributions that have failed for the last time, as well as cleaning up web client interfaces and fileinterface tokens.
The various operations of the Maintenance-tasks are sub-grouped into separate services in the following manner:
However, dependent upon the settings in the AURORA-config file(s) the various operations might be skipped while being checked, because it is not yet their time to be executed or they have been disabled entirely.
Each operation has their own “interval”-setting in the config file (see the sysop-documentation and how to install AURORA).
The maintenance-services will in several cases create new notifications for the Notification-service to handle. The most commons ones are:
These two maintenance-operations are sort of complementary, where one deals with datasets that soon will expire, while the other deals with datasets that are actually expired.
The expired datasets operation will create a special notification that will allow the owner(s) and member(s) of the owner group, and according to their setup, to vote if it is acceptable to remove the dataset in question.
Each time a notification has been created the Maintenance-service will save the time that it was created to avoid multiple creation events. This is true for both sets that are about to expire and sets that have expired. The handling of notifications that are not received or responded to is not part of the things that the maintenance-service handles, but are left to the notification-service (through escalation-events).
When a notification has ended its “life-cycle” the Notification-service will write a FIN-event to the end of it signalling that its work is at an end.
The MAINT_GEN-service will regulary scan the notification-folders to see if it is able to locate any notifications that have the FIN-event on them. In such cases it will investigate further in order to determine if thet type of notification is related to a special notification-type or not. The notification- type determines if it is to be just cleaned up and removed, or something else is going to happen.
A typical special notification-type is the “dataset.remove”-type, which is basically for signalling the wish to remove a dataset. When a FIN-event has been written to such a type of notification, it potentially signals that it is ready to be removed.
When a “dataset.remove” notification has reached its FIN-event, the MAINT_GEN-service will do the following:
When a “dataset.close”-notification has reached its FIN-even, the maintenance-service will do the following:
This maintenance-operation checks for Store-service tasks that have a status as “failed” as well as being the phase “failed”. If both are met and the retries have been exhausted, this operation will deal with the fallout and handling of that.
This operation cleans away any temporary files or data for the various web-client interfaces.
Tokens created through the FileInterface are temporary and have a set expire date and needs to at some point to be removed.
This maintenance-operation will identify tokens that have expired and proceed to remove them. It will add a log-entry on the dataset in question if it removes a token.
Check the database ENTITY_SEQUENCE-table for integrity issues and attempts corrections if needed.
The ENTITY_SEQUENCE-table is important to the functioning of the Aurora-system and ensures that several of the database queries returns results that are consistent with whats in the database.
Checks the database for any changes in PERMISSIONS and render the PERM_EFFECTIVE-tables with the correct information.
This consists of removing connection- and tunneling logs in the system that has expired/passed the threshold for storage time. The default value is 3 months, but can be overridden in the config-file of AURORA.
This cleaning removes entries from the STATLOG- and LOG-tables respectively.