Bug 46066

GemStone/S 64 Bit

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.x, 3.0.1, 3.0, 2.4.8, 2.4.7, 2.4.6, 2.4.5.1, 2.4.5, 2.4.4.8, 2.4.4.7, 2.4.4.4, 2.4.x, 2.3.1.6, 2.3.x, 2.2.6.5, 2.2.5.4, 2.2.x, earlier versions

3.2.13 (linux only)

gslist does not clear locks if another process reused PID

Normally, when server processes die but leave their lock files behind, gslist -v reports these as "killed", and gslist -c will clear the old lock files.

However, if another process starts up and uses the PID that the server process was using, then gslist mistakenly believes that it's the same process.  gslist -v reports it as "frozen", and gslist -c will not clear the lock file since the process is running.

Workaround

Manually delete the lock file.  These are normally in /opt/gemstone/locks/<processname> ..LCK, but the location may be /usr/gemstone/locks/ on older systems, or may be configured using GEMSTONE_GLOBAL_DIR.


                

Last updated: 11/17/17