Bug 50580

Bug: 50580

Impact:

Product:

GemStone/S 64 Bit

Versions:

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.x, 3.2.16, 3.2.15, 3.2.x, 3.1.0.6, 3.1.x

Platform:

Fixed In:

3.7, 3.6.7

setcap impacts stack traces, statmonitor statistics, and linux security mode

To configure Linux to allow huge pages, to protect critical processes from the Linux OOM killer, and to lock the shared page cache in memory, the installation guides direct using setcap to provide specific capabilities to GemStone executables.

This setcap has the effect of changing ownership of files in /proc, which prevents gdb from attaching and thus does not allow pstack or kill -USR1 to collect C stack traces. It also prevents statmonitor from collecting some host process statistics.

Another side-effect is that it puts the process into Linux secure mode (indicated in the gem/topaz log file header by the entry:  getauxval(AT_SECURE) = 1.  This can have various effects on the process, the most notable being the suppression of certain environmental variables, such as $LD_LIBRARY_PATH. See the man pages for ld.so and getauxval for details.

Workaround

For huge pages, an alternative is to define a huge pages group.  Identify or create a group to which all users of the cache belong, create the file /etc/sysctl.d/64-gemstone-local.conf to add the line:
      vm.hugetlb_shm_group = <numericalGidOfGroup>

And reboot or execute sysctl --system.

To reduce the impact of OOM killer protection, do not execute setcap for the gem executables; this allows stack traces for gem processes. You only need to set setcap for stoned and pgsvrmain.  To get stack traces from the Stone, you will need to run gdb as root. To collect memory statistics, give statmonitor the cap_sys_ptrace capacity:

unix> setcap cap_sys_ptrace=pe $GEMSTONE/bin/statmonitor