Article ID: 121470, created on May 6, 2014, last review on Jun 17, 2016

  • Applies to:
  • Operations Automation 5.5
  • Business Automation 5.5
  • Operations Automation 5.4
  • Virtuozzo
  • Virtuozzo containers for Linux
  • Virtuozzo hypervisor


postgresql server is configured with a relatively large (compared to container's amount of RAM) shared_buffers limit:

[root@ct ~] grep ^shared_buffers /var/lib/pgsql/data/postgresql.conf
shared_buffers = 2048MB

Further symptoms may differ, depending on the kernel version.

  • Prior to 2.6.32-042stab085.17:

    postgresql process crashes under excessive loads with SIGBUS error. The following messages written to the log file (/var/lib/pgsql/data/pg_log/postgresql-XXX.log)

    LOG:  server process (PID 859) was terminated by signal 7: Bus error
    LOG:  terminating any other active server processes
    WARNING:  terminating connection because of crash of another server process
    DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
  • After 2.6.32-042stab085.17:

    It is not possible to start postgresql inside containers. The following errors can be found in /var/lib/pgsql/pgstartup.log:

    FATAL:  could not create shared memory segment: Cannot allocate memory
    DETAIL:  Failed system call was shmget(key=5432001, size=2278809600, 03600).
    HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory or swap space, or exceeded your kernel's SHMALL parameter.  You can either reduce the request size or reconfigure the kernel with larger SHMALL.  To reduce the request size (currently 2278809600 bytes), reduce PostgreSQL's shared_buffers parameter (currently 262144) and/or its max_connections parameter (currently 504).
            The PostgreSQL documentation contains more information about shared memory configuration.


Insufficient amount of shared memory exists in the container (as limited by its configuration) or on the hardware node (1/2 of the total RAM).

The processing of shared memory requests from applications was changed in 2.6.32-042stab085.17 kernel. Previously, the applications could request any amount of shared memory for allocation, but crashed on trying to use above the container's limit (which is always equal to 1/2 of container's RAM, by default). Now applications fail with -ENOSPC, when they try to allocate more than the available limit.


There are several possible solutions, depending on the server configuration.

  1. Decrease the size of shared buffers, defined in postgresql configuration.
  2. Increase the amount of RAM, defined for the container (assuming there's available amount of shared memory on the node).
  3. Increase the amount of RAM on the hardware node.

Note: While changing configuration of the container, the total amount of RAM on the hardware node should be taken into account. It may happen that the defined amount of shared memory for container actually exceeds that amount of available shared memory on the node, and the failure of applications will become less obvious in scope of container.

Search Words

Postgresql database won't start after patching to Virtuozzo kernel vzkernel-2.6.32-042stab085.20.x86_64

postgresql fails to start

a26b38f94253cdfbf1028d72cf3a498b 2897d76d56d2010f4e3a28f864d69223 d02f9caf3e11b191a38179103495106f e8e50b42231236b82df27684e7ec0beb 0dd5b9380c7d4884d77587f3eb0fa8ef 5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 614fd0b754f34d5efe9627f2057b8642 5b048d9bddf8048a00aba7e0bdadef37 2554725ed606193dd9bbce21365bed4e ac82ce33439a9c1feec4ff4f2f638899 198398b282069eaf2d94a6af87dcb3ff 801221f8cd76fba7300d1e6817c8e08b 92711db0799e8aefe8e51f12dace0496

Email subscription for changes to this article
Save as PDF