gtmsecshr is a daemon process which enables GT.M to manage M locks and clean up interprocess resources. It starts automatically by any GT.M process that uses its services. Its operation is logged in a file gtm_secshr_log, in the directory specified by the environment variable gtm_log.

For gtmsecshr to operate correctly, it must operate as root. The installation procedure installs gtmsecshr as owned by root with the setuid bit turned on. Any attempt to defeat or bypass this mechanism may result in unpredictable or incorrect operation of GT.M.

IBM S/390 Users

On OS/390 systems, there is not necessarily a unique "root" superuser as there is for other UNIX implementations. For the gtmsecshr daemon to execute correctly, a superuser (e.g., BPXROOT) should be created with a user ID of 0. In addition, on the SUPERUSER statement in the BPXPRMxx parmlib member you must specify the same user ID (e.g., SUPERUSER (BPXROOT)). The gtmsecshr file should be owned by this user ID and should have the setuid bit turned on.

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 from a secondary to a primary. To terminate a gtmsecshr process, use a KILL-15 after shutting down all GT.M processes and running down all database regions.

The gtmsecshr UNIX daemon process must be installed as setuid to root. gtmsecshr requires the additional privileges for it to deliver signals to other processes and to clean up resources that may have been created by other accounts. This daemon enables GT.M to manage M locks and clean up interprocess shared resources used for communication. It is started automatically by any GT.M process needing its services, and it shuts down if there is no activity for 60 minutes. User intervention is not required. Its operation is logged in the gtm_secshr_log file in the directory specified by the environment variable gtm_log.

Fidelity Information Services strongly recommends that all GT.M processes use the same settings for the gtm_log and gtm_tmp environment variables, especially for production environments. This recommendation is made because gtmsecshr inherits these values from whichever GT.M process first uses its services.

When the environment variables of GT.M processes cannot be guaranteed, one way to enforce the values for gtmsecshr is to replace the gtmsecshr executable with a shell script (or with a small C program) owned by root with the setuid bit turned on. This shell script would set the environment variables, and then execute the gtmsecshr executable provided by Fidelity Information Services (which would be placed in a directory accessible only to root to prevent its execution by a non-root process with inappropriate values for gtm_tmp and gtm_log).

If there are multiple GT.M versions active on a system, Fidelity Information Services recommends that all processes of each version use the same values of gtm_log and gtm_tmp. These values should be different for each version. This will ease system administration.

Example

The following is the output of a sample ipcs -ams command on a Compaq/HP Tru64 UNIX system:

Shared Memory:

	
T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIME
m 0 0x3253bc5c --rw-rw-rw- root system root sys tem 2 648 2119 2130 15:42:50 15:42:50 15:42:50
m 2163585 0x430de86c --rw-rw-rw- a8s7r0f8 gtc a8s7r0f8 gtc 1 2530303 31277 31277 11:22:00 no-entry 11:22:00
m 1071490 0x430bbbdf --rw-rw-rw- k3h43k5j gtc k3h43k5j gtc 0 2530303 27374 27374 18:46:46 18:47:02 18:46:46
m 1461123 0x4490b670 --rw-rw-rw- demouser gtc demouser gtc 2 67108864 6612 6612 11:23:37 11:23:37 11:23:37
m 699268 0x4390b670 --rw-rw-rw- demouser gtc demouser gtc 2 67108864 15177 30277 11:23:37 11:18:22 11:18:22
m 491141 0x4390b66f --rw-rw-rw- demouser gtc demouser gtc 2 2580991 4834 30277 11:23:37 no-entry 11:18:22
m 494854 0x439032c3 --rw-rw-rw- m34z gtc m34z gtc 0 1224191 4193 4193 11:24:35 11:25:59 11:24:35
m 343693 0x43909d3e --rw-rw-rw- u324xe4 gtc u324xe4 gtc 0 2530303 6358 17655 12:32:14 13:34:05 12:30:58
	

Semaphores:

	
T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME 
s 0 0x418b059d --ra------- root system root sys tem 1 15:41:43 15:41:43
s 1680769 0x430de86c --ra-ra-ra- a8s7r0f8 gtc a8s7r0f8 gtc 3 11:22:00 11:22:00
s 828226 0x430bbbdf --ra-ra-ra- k3h43k5j gtc k3h43k5j gtc 3 18:46:47 18:46:46
s 1010819 0x4490b670 --ra-ra-ra- demouser gtc demouser gtc 4 11:23:37 11:23:37
s 521988 0x4390b670 --ra-ra-ra- demouser gtc demouser gtc 3 11:23:37 11:18:22
s 388293 0x4390b66f --ra-ra-ra- demouser gtc demouser gtc 3 11:23:37 11:18:22
s 328454 0x439032c3 --ra-ra-ra- m34z gtc m34z gtc 3 11:24:35 11:24:35
s 249293 0x43909d3e --ra-ra-ra- u324xe4 gtc u324xe4 gtc 3 12:32:14 12:30:58
	

In this case, the IPC resources owned by root are used by UNIX for its processing. Those owned by "demouser" pertain to a GT.M instance with a Journal Pool, a Receive Pool, and a single database region.

To identify them, you can run the ftok utility program that resides in the GT.M distribution directory. The following is a sample output of the ftok mumps.gld mumps.dat command:

	KEY		NATTCH		NSEMS
	mumps.dat :: 	26261103 	[0x4390b66f ]
	mumps.gld :: 	26261104 	[0x4390b670 ]
	

mumps.dat is the database file for the single database region. The shared memory and semaphore set with 0x4390b66f in the KEY column above correspond to the database file. Note that there are two processes attached to the shared memory (there is a "2" in the NATTCH column) and three semaphores in semaphore set (there is a "3" in the NSEMS column). There will be a similar shared memory segment and a semaphore set for each open database file.

mumps.gld is the Global Directory file, and the shared memory and semaphore set with 0x4390b670 in the KEY column above correspond to the Journal Pool. Again, there are two attached processes and three semaphores. Unless there are multiple primary/secondary instances of GT.M on the same machine, there should be only one Journal Pool.

The KEY for the Receive Pool is the same as the KEY for the Journal Pool with the leading 0x43 replaced by 0x44. The shared memory and semaphore set with 0x4490b670 in the KEY column correspond to the Receive Pool. There are four semaphores in this semaphore set, and two attached processes. Unless there are multiple primary/secondary instances of GT.M on the same machine, there should be only one Receive Pool.

For simple GT.M operation (i.e., no replicated primary or secondary databases), there will be no Journal Pool or Receive Pool.

Some shared memory regions have 0 processes attached to them (the NATTCH column). If these correspond to GT.M database regions or to Global Directories, these result from improper process termination of GT.M and GT.M utility processes (GT.M processes show up as "mumps" in a UNIX ps command); Source Server, Receiver Server, or Update Processes (which appear as "mupip"); or other GT.M utilities ("mupip", "dse", or "lke").

IPC resources that correspond to GT.M database regions but do not have attached processes can usually be cleaned up. To do this, run down the database with a mupip rundown command for the corresponding database file or region. If the mupip rundown does not work, the following is possible:

If mupip rundown does not clean up a resource (and the versions of GT.M and mupip match), then use the UNIX command ipcrm to clean up the resource. In this case, check the database for integrity errors (both structural errors as well as application consistency errors).