Hi, I'm setting up Engine for the 2nd time - the first time I answered a configuration question wrong. So I did: engine-setup engine-cleanup engine-setup Things worked, until I rebooted the system. I found that postgresql would not startup, and was failing with "could not create shared memory segment: Invalid Argument". I resolved this issue by creating a file /etc/sysctl.d/10-shmmax.conf, containing the line: kernel.shmmax = 1000000000 (I read somewhere that postgresql recommends setting shmmax to 1/4 of physical memory, and I have 4GB) 1. Is this a known bug? If not, should I file one? If so, how do I do that? :)

2. Is there a better fix than the one I settled on? Does the normal configuration wind up increasing shmmax, or reducing postgresql's limits? What are the default values for this in a normal engine configuration?

Thanks, Bob _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

On 11/04/2013 05:43 AM, Sandro Bonazzola wrote: > Il 02/11/2013 17:51, Bob Doolittle ha scritto: >> Hi, >> >> I'm setting up Engine for the 2nd time - the first time I answered a configuration question wrong. So I did: >> >> engine-setup >> engine-cleanup >> engine-setup >> >> Things worked, until I rebooted the system. I found that postgresql would not startup, and was failing with "could not create shared memory segment: >> Invalid Argument". >> >> I resolved this issue by creating a file /etc/sysctl.d/10-shmmax.conf, containing the line: >> kernel.shmmax = 1000000000 >> >> (I read somewhere that postgresql recommends setting shmmax to 1/4 of physical memory, and I have 4GB) >> >> 1. Is this a known bug? If not, should I file one? If so, how do I do that? :) > Which version are you installing? 3.3, on Fedora 19. > Can you please attach all 3 logs from above sequence (setup, cleanup, setup)? > I think something may have gone wrong on second setup execution while setting shmmax. Unfortunately I no longer have those logs. *However* last night I powered down my node and engine. Last night engine would at least come up. Now when I boot up my engine I get the same error. So my guess is that the shmmax setting isn't being configured in a persistent fashion somehow, or is somehow reverting. My most recent setup log is here (I hate to send large logs to lists): https://dl.dropboxusercontent.com/u/35965416/ovirt-engine-setup-201311031...

-Bob >> 2. Is there a better fix than the one I settled on? Does the normal configuration wind up increasing shmmax, or reducing postgresql's limits? What are >> the default values for this in a normal engine configuration? > No better fix, engine-setup just do something like that, setting shmmax to 35554432. > > >> Thanks, >> Bob >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users

On 11/05/2013 02:13 AM, Sandro Bonazzola wrote: > Il 04/11/2013 17:17, Bob Doolittle ha scritto: >> On 11/04/2013 05:43 AM, Sandro Bonazzola wrote: >>> Il 02/11/2013 17:51, Bob Doolittle ha scritto: >>>> Hi, >>>> >>>> I'm setting up Engine for the 2nd time - the first time I answered a configuration question wrong. So I did: >>>> >>>> engine-setup >>>> engine-cleanup >>>> engine-setup >>>> >>>> Things worked, until I rebooted the system. I found that postgresql would not startup, and was failing with "could not create shared memory segment: >>>> Invalid Argument". >>>> >>>> I resolved this issue by creating a file /etc/sysctl.d/10-shmmax.conf, containing the line: >>>> kernel.shmmax = 1000000000 >>>> >>>> (I read somewhere that postgresql recommends setting shmmax to 1/4 of physical memory, and I have 4GB) >>>> >>>> 1. Is this a known bug? If not, should I file one? If so, how do I do that? :) >>> Which version are you installing? >> 3.3, on Fedora 19. >> >>> Can you please attach all 3 logs from above sequence (setup, cleanup, setup)? >>> I think something may have gone wrong on second setup execution while setting shmmax. >> Unfortunately I no longer have those logs. >> >> *However* last night I powered down my node and engine. Last night engine would at least come up. >> >> Now when I boot up my engine I get the same error. So my guess is that the shmmax setting isn't being configured in a persistent fashion somehow, or >> is somehow reverting. >> >> My most recent setup log is here (I hate to send large logs to lists): >> https://dl.dropboxusercontent.com/u/35965416/ovirt-engine-setup-201311031... > 2013-11-03 14:18:18 DEBUG otopi.plugins.ovirt_engine_setup.system.sysctl plugin.execute:441 execute-output: ('/sbin/sysctl', '-n', 'kernel.shmmax') > stdout: > 35554432 > > setup detected that your shmmax is already configured with a good value so it didn't change the configuration. > If you set above value before running setup, please retry running setup without setting it or setting it to a value less than 35554432. > setup will detect it's too low and will create needed configuration files for fixing it. Except that when the system booted postgresql failed to come up because it failed to allocate the shm segment it wanted, and when I checked /proc/sys/kernel/shmmax the value was much lower than that. I have again set the value in syscfg and things are working now. So my guess is that something is reverting the value after engine-setup has set it, or else somehow it was not set in a persistent fashion by engine-setup. Where is the shmmax value stored by engine-setup? Should there be a file in /etc/syscfg.d? There was not.

-Bob

On 11/05/2013 10:17 AM, Sandro Bonazzola wrote: > the file created by engine-setup is /etc/sysctl.d/ovirt-engine.conf. > Note that the file is created by engine-setup only if shmmax is < > 35554432 when it's running. Hmmm, I think this explains the initial problem I saw, after doing setup; cleanup; setup The first setup will bump up the shmmax. The cleanup will remove ovirt-engine.conf. However if you don't reboot, shmmax remains boosted. The second setup will detect that shmmax is fine, and not create ovirt-engine.conf. A subsequent reboot will revert shmmax to the default value, and postgresql will fail to come up. -Bob

This boils down to "Current runtime state" !=3D "Current configuration",=

but you are basing configuration decisions on the runtime state. These=0A= situations are always thorny to deal with.=0A= =0A= -Bob=0A=