----- Original Message -----
From: "Joop" <jvdwege(a)xs4all.nl>
To: "Dave Neary" <dneary(a)redhat.com>
Cc: "users" <users(a)ovirt.org>
Sent: Friday, September 21, 2012 9:57:02 AM
Subject: Re: [Users] Installation problem
Dave Neary wrote:
>
>
> It turns out, in /var/log/messages, that I have these error
> messages:
>> Sep 21 14:00:59 clare pg_ctl[5298]: FATAL: could not create
>> shared
>> memory segment: Invalid argument
>> Sep 21 14:00:59 clare pg_ctl[5298]: DETAIL: Failed system call
>> was
>> shmget(key=5432001, size=36519936, 03600).
>> Sep 21 14:00:59 clare pg_ctl[5298]: HINT: This error usually
>> means
>> that PostgreSQL's request for a shared memory segment exceeded
>> your
>> kernel's SHMMAX parameter. You can either reduce the request size
>> or
>> reconfigure the kernel with larger SHMMAX. To reduce the request
>> size (currently 36519936 bytes), reduce PostgreSQL's shared memory
>> usage, perhaps by reducing shared_buffers or max_connections.
>> Sep 21 14:00:59 clare pg_ctl[5298]: If the request size is already
>> small, it's possible that it is less than your kernel's SHMMIN
>> parameter, in which case raising the request size or reconfiguring
>> SHMMIN is called for.
>> Sep 21 14:00:59 clare pg_ctl[5298]: The PostgreSQL documentation
>> contains more information about shared memory configuration.
>> Sep 21 14:01:03 clare pg_ctl[5298]: pg_ctl: could not start server
>> Sep 21 14:01:03 clare pg_ctl[5298]: Examine the log output.
>> Sep 21 14:01:03 clare systemd[1]: postgresql.service: control
>> process
>> exited, code=exited status=1
>> Sep 21 14:01:03 clare systemd[1]: Unit postgresql.service entered
>> failed state.
>
> I increased the kernel's SHMMAX, and engine-cleanup worked
> correctly.
>
> Has anyone else experienced this issue?
Yes, not related to oVirt but on a database server also running
Postgres. It seems that either the package maintainer is very
conservative or postgres itself is. Standard on the Debian 6 server
was
also very low shmmax.
What is the OS you run ovirt-engine on?
I'm going to take a stab and guess Fedora. This came up for an unrelated reason in
#fedora-devel the other day, because Fedora (and I suspect Debian as well) has a policy of
sticking as close to upstream as possible it uses the shmmax of the upstream kernel -
which is as you note quite low. In RHEL and other EL6 derivatives this value is modified
and set much higher.
Steve