IBM Support

Various DB2 failures may occur on Linux with Address Space Layout Randomization (ASLR)

Troubleshooting


Problem

ASLR (Address Space Layout Randomization) is a feature that is enabled by default on most Linux distributions. It is designed to improve security by loading shared memory objects at random addresses instead of fixed addresses.  In DB2, multiple processes attempt to map a shared memory object at the same address, which does not work reliably when ASLR is enabled, due to "address space conflicts".

Symptom

An "address space conflict" occurs when a process trying to attach a shared memory object to a specific fixed address fails because the current randomized address space layout conflicts with the specific fixed address being used.  This is observed as a failure in the shmat subroutine.
 
FUNCTION: DB2 UDB, SQO Memory Management, sqlocshr, probe:180
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
          "No Storage Available for allocation"
          DIA8305C Memory allocation failure occurred.
CALLED  : OS, -, shmat                    OSERR: EINVAL (22)
A subsequent attempt (which uses a new process) might have a different randomized address space layout, which might not conflict with the specific address being used, and might not see this failure.

Due to the random nature of the address space layout, these failures can occur randomly.

Various commands can encounter this problem, including db2pd, db2egcf, db2vend and db2fmp.
The db2pd command (used for diagnostics) can print the following message:
 
Exceeded re-exec max count trying to attach to the database manager. This is likely due to ASLR currently being enabled on this system. Please retry the db2pd command.

The db2egcf process (used for HA monitoring) might incorrectly determine that the instance is down and initiate a failover.
 
The db2vend process (used for backup and log archiving) might fail with an error indicating a child process could not be started:
 
SQL2043N  Unable to start a child process or thread.

The db2fmp process (used for fenced UDFs and stored procedures) might fail with an error:
 
$ db2 "SELECT T.RESULT FROM T1, TABLE(MYUDF(T1.C1)) AS T"
RESULT
------------------------
SQL0430N  User defined function "MYUDF" (specific name "SQL123456789012345") has abnormally terminated.  SQLSTATE=38503  

Diagnosing The Problem

When this problem is suspected, check db2diag.log for the shmat failure, such as the following.  The same error message can also occur for a different causes, so it is important to note the process that reported the error.
 
FUNCTION: DB2 UDB, SQO Memory Management, sqlocshr, probe:180
MESSAGE : ZRC=0x850F0005=-2062614523=SQLO_NOSEG
          "No Storage Available for allocation"
          DIA8305C Memory allocation failure occurred.
CALLED  : OS, -, shmat                    OSERR: EINVAL (22)

Resolving The Problem

Retrying the command creates a new process, which might be able to attach to the shared memory, but might still fail to attach.  Multiple retries can be required.
The best resolution is to disable ASLR with one of the following methods:
1) Disable ASLR temporarily (change is only effective until next boot):
 
Run "sysctl -w kernel.randomize_va_space=0" as root.

2) Disable ASLR immediately and on all subsequent reboots:
 
Add the following line to /etc/sysctl.conf:
kernel.randomize_va_space=0

Then run "sysctl -p" as root to make the change take effect immediately.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSEPGG","label":"Db2 for Linux, UNIX and Windows"},"Component":"Operating System \/ Hardware - Other OS\/Hardware","Platform":[{"code":"PF016","label":"Linux"}],"Version":"11.5;11.1;10.5;10.1;9.7;9.5","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Document Information

Modified date:
05 August 2022

UID

swg21365583