SharedMemory issues

cubber · #1 02-08-2009, 07:58 PM

I just built a new gentoo server using the minimal cd. Then I just installed Apache, Mysql, and PHP on the server as well as eqemu. I pulled down the latest svn rev 308 and built it. I then moved my old db from my old server which was running gentoo and svn rev 291. I updated the db to the latest in cvs rev 303 then applied the rev 304 update in the utils/sql/svn folder.

When I started the server for the first time I get this error:

Code:

SharedMemory->datasize(0) != iSize(44684392), We can rebuild him faster better STRONGER!

Which most of us have seen before form these 2 threads:

http://www.eqemulator.net/forums/sho...ghlight=shmmax

and

http://www.eqemulator.net/forums/sho...ghlight=shmmax

I increased the kernel.shmmax size to 128M before I even installed the EQEMU server. Because I had anticipated this issue would surface if I did not do so before installing the emulator.

Notice how the shared memory size in the error increased since the previous threads. I even tried bumping the kernel.shmmax size to 192M without any luck.

I then updated my old server to the latest svn and db so they matched the new server, and it does not exhibit this issue. The kernel.shmmax size is set to 128M on that server.

Any ideas?

cubber · #2 02-08-2009, 08:45 PM

I tried wiping the server directory and rebuilding from clean sources, then I also created a new clean default PEQ db and tested the server. I still get the same issue. The only real difference between the old server and the new one besides the old one is an intel celeron and the new one is an athlon-xp is that the new one I am using the gentoo hardened profile with hardened sources and the old one uses the normal gentoo-sources for a kernel with a default gentoo desktop profile.

I am wondering if there is something with the hardened kernel that is causing this.

cubber · #3 02-10-2009, 12:27 PM

Well its not the hardened profile or sources, I just rebuilt the entire system using Gentoo with the standard 2008.0 server profile and a standard stable gentoo-sources:2.6.27-r8 kernel. The only difference between the two servers now is the kernel version

The new system is using 2.6.27-r8

the old is using 2.6.26-r4

cubber · #4 02-10-2009, 12:51 PM

A couple of interesting observations between running the server under hardened and standard gentoo.

Under hardenend the system seems much more responsive and the game deffinitly loads faster on the clients end. (zoning and such)

I do not have any ghosting issues at all running under hardened. Under standard I have the "pull and mob goes through you then warps back" issue.

When I compiled under hardened I added the following cflags in the makefiles:

Code:

-O2 -march=athlon-xp -ffomit-frame-pointer -fforce-addr

Code:

I also tried compiling with out the -ffomit-frame-pointer and -fforce-addr

and got similar results.

Under standard I use the following:

Code:

-O2 -march=athlon-xp

Note that the hardened profile uses gcc 3.xx and the standard uses 4.x so this could also be the cause some of the improvments I am seeing. Also when I tried to compile PAX and GRSECURITY into the kernel I could not even run the eqemu server due to memory space security restrictions.

Guess since they both are displaying the SharedMemory error after a clean install I am gonna blow out the sytem again and reinstall with hardened, since it is an obvious improvement over standard server.

John Adams · #5 09-28-2009, 01:20 PM

This does not appear to be getting the attention it deserves. Real pain in the ass having to wait til your server starts completely, to take it down, then restart it because of this mysterious error. I can't even tell you something is actually wrong, just the message states to restart the servers.

All you Windows-hating NIX gods out there, have no advice for us? I'd like to see this resolved as well. Do we need a bigger shmmax now?

cubber · #6 09-28-2009, 01:32 PM

I had this corrected on my box for quite a while by upping the value, then after an update it reappeared. No matter how high I put the setting it always pops back up. I just have bitten the bullet and now just accept it as a process I need to do each time I have to start the server after a reboot.

It does suck! and has been a known bug for about a year now. I don't even start my login server anymore until after I run the server once to get rid of the error. Then I put up my login server and restart the server clean.

What I want to know is what does the startup script actually do to "fix" the issue when it errors, and has you restart after saying:

"we can build it stronger faster... restart all servers"

Couldn't this "adjustment" be applied right from the start to prevent this from happening? Obviously something is fixing the issue after the first run, so you can run it a second time without the error...

cubber · #7 09-28-2009, 01:36 PM

On a side note if you watch your crashlog file you will see a crash reported when the startup happens and you get to the error point. Then the server actually goes through the process of restarting itself, so you really don't need to stop then start it again. I just do it for sake of cleanliness.