IBM Support

Informix utilities cannot attach to shared memory, errno 22, on Linux Red Hat

Troubleshooting


Problem

This article describes a kernel configuration problem which can cause ontape, oncheck to fail to attach to virtual shared memory segment on Linux Red Hat.

Resolving The Problem


PROBLEM

The ontape utility can fail to attach to virtual shared memory with the following error during logical log backup:

    shmat: [22]: operating system error
    Logbackup failed - function write to

            tape failed code -1 errno 14

CAUSE

This can be caused by the operating system (OS) creating multiple OS memory segments for an Informix shared memory segment because of kernel parameter SHMMAX being configured low.

Example

The onconfig parameter SHMVIRTSIZE and the kernel parameter SHMMAX are set to 167772160 and 33554432 bytes respectively. The SHMVIRTSIZE parameter specifies the size of the virtual portion of shared memory to allocate when you initialize the database server. The SHMMAX parameter specifies system-wide maximum allowable shared memory segment size. Following is an 'onstat -g seg' output, showing all Informix shared memory segments:
     
In general, ‘key’ values in ‘onstat -g seg’ output are sequential numbers. However, in this scenario key values are not sequential. Due to low SHMMAX size, Informix resident and virtual shared memory segments broken down into multiple OS memory segments. Following 'ipcs -m' command showing, Informix resident and virtual segment are consists of 5 OS memory segments each:

Informix utilities, i.e., ontape, onbar, oncheck, etc. create their own threads to perform respective operation and for each threads database server creates thread-control block in the virtual portion of shared memory segment.

When an Informix utility process starts, it tries to attach to the Informix virtual shared-memory segment and supplies the unique key value to OS for identify the segment. In return, the OS passes back a shared-memory segment identifier associated with the key value. Using this identifier, the process requests to the OS attach the segment of shared memory to the process address space.

In this scenario, the ontape process sent 0x52574806 as unique key for first Informix virtual segment to the OS. In return, the OS passed back 14090247 as shmid because the first OS memory segment (shmid 14057478) is full. However, shmid 14090247 is invalid in respect to Informix shared memory segments because there is no key associated with that shmid.


SOLUTION

Choose one of following options:
  • Tune the SHMMAX kernel parameter
  • Set onconfig parameter SHMVIRTSIZE and SHMADD same as SHMMAX kernel parameter


EXAMPLES

The following are some Linux operating system commands to determine and change the value of SHMMAX:
  • Determine the maximum size of a shared memory segment:
    • # cat /proc/sys/kernel/shmmax
  • The default shared memory limit for SHMMAX can be changed in the proc file system without reboot:
    • # echo 2147483648 > /proc/sys/kernel/shmmax
  • Alternatively, can use sysctl to change SHMMAX:
    • # sysctl -w kernel.shmmax=2147483648
  • To make a change permanent, add the following line to the file /etc/sysctl.conf. This file is used during the boot process.
    • # echo "kernel.shmmax=2147483648" >> /etc/sysctl.conf

[{"Product":{"code":"SSGU8G","label":"Informix Servers"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Not Applicable","Platform":[{"code":"PF016","label":"Linux"}],"Version":"10.0;11.1;11.5;7.3;9.2;9.3;9.4;11.7","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
16 June 2018

UID

swg21238293