gmtsecshr

The GT.M installation script installs gtmsecshr as owned by root and with the setuid bit on. gtmsecshr is a helper program that enables GT.M to manage interprocess communication and clean up interprocess resources. It resides in the $gtm_dist/gtmsecshrdir subdirectory which is readable and executable only by root. gtmsecshr is guarded by a wrapper program. The wrapper program protects gtmsecshr in the following ways:

gtmsecshr automatically shuts down after 60 minutes of inactivity. Normally, there is no need to shut it down, even when a system is making the transition between a secondary and a primary. The only occasions when gtmsecshr must be explicitly shut down are when a GT.M version is being removed - either a directory containing the GT.M version the running gtmsecshr process belongs to is being deleted, or when a new GT.M version is being installed in the same directory as an existing one.

[Note] Note

FIS strongly recommends against installing a new GT.M version on top of an existing GT.M version.

To terminate a gtmsecshr process, use a KILL-15 after shutting down all GT.M processes and running down all database regions in use by GT.M in that directory.

[Important] Important

FIS strongly recommends that all GT.M processes that use a given version of GT.M use the same settings for the gtm_log and gtm_tmp environment variables. gtmsecshr inherits these values from the GT.M process that starts it. Not having common values for gtm_tmp and gtm_log for all processes that use a given version of GT.M can have an adverse impact on performance.

If there are multiple GT.M versions active on a system, FIS recommends different values of gtm_tmp and gtm_log be used for each version. This makes system administration easier.

[Caution] Caution

A given database file can only be open by processes of a single version of GT.M at any given time. Contemporary releases of GT.M protect against concurrent access to GT.M files by processes executing different versions of GT.M. Since historical versions of GT.M did not protect against this condition, FIS recommends procedural safeguards against inadvertent concurrent access by processes of multiple versions on systems on which old versions of GT.M are installed and active, since such concurrent usage can cause structural damage to the database.