Bug 21365

Bug: 21365

Impact:

Product:

GemStone/S

Versions:

6.7.2.1, 6.7.2, 6.7.1, 6.7, 6.6.5, 6.6.4, 6.6.3.3, 6.6.3.2, 6.6.3, 6.6.2, 6.6.1, 6.6, 6.5.8, 6.5.7.5, 6.5.7, 6.5.6, 6.5.5, 6.5.4, 6.5.2, 6.5.1, 6.5, 6.3.1, 6.3, 6.2.x, 6.2, 6.1.6, 6.1.5, 6.1.x, 6.0.x, 5.1.5.1, 5.1.5, 5.1.4

Platform:

All

Fixed In:

startstone or login fail with misleading shmget() error

When STN_MAX_SESSIONS and keyfile maximum sessions are out of synch,
startstone or login fails with the following misleading error message
in the shrpcmon log:

   <SHRPCMON, shell for GemStone SharedPageCache Monitor>
   <Taking commands from command line.>
    [SpcMon trace]: ... cache creation failed ...
   |   GemStone could not retrieve the IPC identifier associated with the memory |
   |   key 1275488407.  shmget() error = errno=17, EEXIST, The file already exists.
   |                                                                             |
   GemStone could not retrieve the IPC identifier associated with the memory
   key 1275488407.  shmget() error = errno=43, EIDRM, Identifier removed
   (resource such as semaphore or shared memory has been deleted.
   GemStone could not attach to the shared page cache.
   The Shared Page Cache Monitor is shutting down.
   The Shared Page Cache Monitor is shutting down.

This can occur when a Gem's configuration file specifies a
SHR_PAGE_CACHE_NUM_PROCS less than that of the Stone it is logging in
to, or when a keyfile specifies a maximum number of users that is much
less than the STN_MAX_SESSIONS of its configuration file.

Workaround

Set STN_MAX_SESSIONS in the configuration file to reasonably
close to (or the same as) the keyfile limit.