gmtsecshr

gmtsecshr
Prev	Appendix A. GT.M's IPC Resource Usage	Next

The GT.M installation script installs gtmsecshr as owned by root and with the setuid bit on. gtmsecshris 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:

It restricts access to gtmsecshr in such a way that processes that do not operate as root cannot access it except though the mechanism used by the wrapper.
Environment variables are user-controlled input to gtmsecshr and setting them inappropriately can affect system operation and cause security vulnerabilities. While gtmsecshr itself guards against this, the wrapper program provides double protection by clearing the environment of all variables except gtm_dist, gtmdbglvl, gtm_log, and gtm_tmp and truncating those when they exceed the maximum allowed length for the platform.
gtmsecshr logs its messages in the system log. These messages can be identified with the GTMSECSHR facility name as part of the message. GT.M processes communicate with gtmsecshr through socket files in a directory specified by the environment variable gtm_tmp.

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
	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
	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
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.

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.

Prev	Up	Next
Examining GT.M's IPC Resources	Home	Appendix B. Monitoring GT.M