Shared memory error when starting server after reboot.
 

Whenever I start my server after a reboot I always see the following:

SharedMemory->datasize(0) != iSize(36508172), We can rebuild him faster better STRONGER!
Or not.. restart all servers on this machine

I run gentoo linux and have applied the shmmax fix as noted in this post which corrected the shmat issue from before but this new error just start popping up a few server revisions ago. Basically I just restart the server and it is fine until the PC is rebooted then I get the line again. If I stop the server then start it again without rebooting the pc I do not get the error.

I have the following line added to /etc/sysctl.conf:
kernel.shmmax = 134217728

and also did the command /sbin/sysctl -p to make it permanent.

When I run:
cat /proc/sys/kernel/shmmax

it returns:
134217728

Any help is appreciated.

I had this this morning after a server crash I restarted world and it was good.

Try rebooting your PC and then start the eqemu server up again you will get the same message and will have to stop the eqemu server and restart it for it to go away. Then it will be good until your server reboots , then you will have to do the process over.

Look for my post about "shmmat" issues. There are a few solutions in there to make a perma change to your kernal.shmmax size.

Thanks for the reply John but I did follow all the directions in that post a while ago. Also in my first post in this thread I listed the values:

From the top:

I have the following line added to /etc/sysctl.conf:
kernel.shmmax = 134217728

and also did the command /sbin/sysctl -p to make it permanent.

When I run:
cat /proc/sys/kernel/shmmax

it returns:
134217728

I have same problem. I have increased my shmmax and it persists after reboots. I'm running Eqemu 0.7.0-1070 on ubuntu with a clean install, and a fresh database from peq cvs.

On first load of world I get

It only displays on first world run after a server boot. It's not just a nuisance for me, since I also am getting this on zone launches:
I can run 0.7.0-989 just fine, dunno about any versions in between. I've been struggling with this for a couple weeks now off and on. Lend me your head so I can pull out your hair too pls.

I am still struggling with this. Has anyone else experienced this problem?

Would suggest the version of zone/world and libEMuShareMem.so are incompatible. When you run the 1070 server, are you sure it is picking up the 1070 version of zone/world and libEMuShareMem.so ?

E.g. you might have an older version of any of these files in your PATH or LD_LIBRARY_PATH which it is picking up before the 1070 versions, leading to it trying to e.g. run the 1070 zone/world with the 989 libEMuShareMem.so or any cominbation thereof.

Sorry if this is obvious and you already ruled this out, but I can't think what else it could be.

Every compile I destroy my working server directory and copy in files from a build directory. But I may be linking to an old build directory instead of my working server directory. I'll check it out.

Win or lose, thanks for the help.

DB table struct error
 

This can be caused by a table in the db that dosent have the correct columns for the release of your compiled Emusharemem lib file. Look through the changelog for the release and make sure your DB table struct is current with 107x.

Krusher

Thanks, I have applied the necessary changelog changes, followed by dropping the entire database to load the peq database to ensure I hadn't made a mistake.


I found out that I was using the wrong libEMuShareMem.so, I had my old .so in /lib and so it didn't load the correct one in my working server directory. I removed the file and ln'd to the one in my server directory to avoid having this problem in the future.

Thanks all for the help.

Well previous help has cleared up my libEMu problems, but I'm still getting
on first server run.

Server and zones will load and wait a connection. I can get to the character select screen, but on "enter world" my server console reads:

My client gets a near immediate zone unavailable error.

turned out the peq db requires changelog sql fixes. I had assumed otherwise.

Server is up, thanks for the help.

If you required updates, then you are using the wrong CVS address, and aren't using the current db.