I got shmat issues...

[John Adams]

I took a stab at fixing the 13th Floor Item import script (by actually fixing the Items table itself). On my Windows test box, all went swimmingly - server booted, I was able to log in and see the nearly 6,000 new items.

Sourced the new items table over to my Linux server, and it sh*t the bed, so to speak. When "world" launches, it spits out this error message:

failed to get 0-length shared mem: Cannot allocate memory
shmat failed! Invalid argument

Upon investigating what "shmat failed!" is, I tracked it down to MMF.ccp, around line 210 in the current CVS. It's in an "#IFDEF... #else //else, NOT WINDOWS" section. Which is why Windows seems fine, but Linux craps out.

if(share_id == -1) {
cerr << "failed to get 0-length shared mem: " << strerror(errno) << endl;
}
if ((lpvMem = shmat(share_id, NULL,SHM_RDONLY)) == (void *)-1) {
cerr << "shmat failed! " << strerror(errno) << endl;
}

Now, I know little next to nothing about C++, let alone shared memory. If there is a dev around that sees this, can you please advise what can be done to (maybe) expand the limits of shared memory on Linux servers? This is on a Fedora Core 4 box, if it matters.

I'd love to release a patch to the Items table for others, but right now I am uncertain the current code can handle it (not that many of the items are usable anyway ;))

For anyone ambitious enough to try a newer items table, grab it here (http://eq.mmoemulators.com/files/items20070719.zip). This was updated using teh 13thFloor Items file dated 7/6/2007 (or thereabouts).

Be sure to backup your data, eh? This likely will not work as much as you'd hope.

[gernblan]

Thank you!

I'll play with this on my dev server (it's running Ubuntu at the moment) and if I can duplicate this problem and solve it, I'll tell you what I did to do so :)

[gernblan]

For one thing, what's with all the extra fields?

Not that they will get in the way, per se, but they are certainly not needed and make db merging a whole lot more difficult.

[John Adams]

It is how you fix the 13th floor import .pl. Columns have to match 13th Floor data file. As for merging, that's an individuals problem. :) All I did was find a way to get the latest 13th Floor into a raw, non-customized Items table. The extra columns are new attribs for (maybe) the newer items from that data source.

Then, ran into problems with nearing the max item ID ceiling, and this thing on Linux which I have had no time to look into. If you can fix it, great!

[gernblan]

Still working on this. It's not a max items thing... something else is strange.

[John Adams]

Remember, it appears fine on Windows and is only in the "not win32" code. Not sure if that helps narrow the search...

[sdabbs65]

Remember, it appears fine on Windows and is only in the "not win32" code. Not sure if that helps narrow the search...

Dunno if this helps but I got this fro ma old thread...

Too many items, edit
common/Items.h
and change the value of
#define MMF_EQMAX_ITEMS 85000
to find the number of items in your database, run the following query :
select max(id) from items;

[John Adams]

Thanks sdabbs. The item id's are still a few thousand below the current max (100,000), so I don't think that's the issue on Linux. Especially because Windows emu doesn't seem to have the problem. I guess I need to learn what a shmat is. :)

[sdabbs65]

I guess I need to learn what a shmat is. :)

Isn't it that monkey from buck rodgers?
http://man.he.net/man2/shmat

[John Adams]

Crap, now I know _everything_! What will I do now?

Thanks man, that sheds a little more light on the problem.

[Lalolyen]

JA are you still having this problem? I think I hit a problem simular to this about a week ago and fixed it....

[John Adams]

Only when I source in the new 13th Floor items list on Linux, yes.

The PEQ Items table is fine.

I'll take a fix if ya got one. :)

[WildcardX]

Has anyone found a fix for this? I'm starting to look at this myself and am somewhat baffled by why the shmget function call is failing at line 205 of MMF.cpp.

[WildcardX]

The solution to this problem isnt in the server code. Its fixable by your distros configuration. You need to increase the value in your /proc/sys/kernel/shmmax file to some value greater than 32 MB. The value in that files in is bytes and its probably going to vary from distro to distro. I'm not sure what a good value is, but i can confirm setting it to 100 MB does allow us to import the current 13th floor items table.

Enjoy!

I also want to thank both Cavedude and FatherNitWit for assisting me in identifying this issue and testing the solution. I believe you can expect PEQ to have a current items table in the next few days now.

[cavedude]

Here we are, a brand new items table consisting of the newest 13th floor dump as of this morning (62,000+ items) Stackable items work, and I made the appropriate changes to the columns so all the data got converted and merged in. I've been testing it all morning and had no issues (other than pre-existing ones in the Emu code of course) so it looks like we are good.

http://projecteq.net/items_102107.rar

As Wild said, Linux users will probably need to bump your /proc/sys/kernel/shmmax file a bit. Windows users need not do anything.

[uncommon]

Many thanks cavedude. Sourced it np.

[cavedude]

The following changes are needed:

update items set stackable = 1 where clickeffect = -1 and maxcharges = 1;
update items set stackable = 1 where itemtype in (14,18,28,55,15,19,37,56,17,27,38,53,21);
update items set casttime = casttime_;
update items set stackable = 1 where name like 'Spell:%' and itemtype = 20;
update items set slots = 2097152 where slots = 4194304;

Some more itemtypes were added as being stackable, food/drink consumption is fixed, and many ammo slot items are now fixed. The players on PEQ didn't really find any other bugs with the new table so after this update all should be good. If more updates are needed, however I will post.

[cavedude]

More fixes bard spells and items:


update items set slots = 2099200 where slots = 4196352;
update items set stackable = 1 where name like 'Song:%' and itemtype = 20;

[John Adams]

Excellent guys, thank you for bringing this to a conclusion.

Cavedude, are the updates you mentioned in the peq-db svn? If so, I'll just continue to source from there. Thanks again!

[cavedude]

They will be by the end of the day :)

[John Adams]

A temporary solution appears to be running this on my Linux FC4 server:

echo 83886080 > /proc/sys/kernel/shmmax

This sets my current shared memory at 80mb, but when I reboot it will go back to the default 32mb. This is where things get scarey with Linux for me; the perma fix is to change Kernel source and recompile. I have never done this, and I will certainly screw things up :)

Some general info about making this change permanent (related to installing Ingres, but still informative):
3.3. Kernel Parameters
The default settings of the Linux kernel are adequate for a development Ingres environment. For a live system, however, probably to increase the size of the database cache(s), you may want to change the built-in value of the SHMMAX parameter. This parameter sets the maximum size of a shared memory segment. By default, it is 32 Mb which allows for a somewhat lesser buffer cache.

You have two choices to change the value of SHMMAX:

As root, simply echo the new value into /proc/sys/kernel/shmmax:

#echo 83886080 > /proc/sys/kernel/shmmax

In the example above, we set the value of SHMMAX to 80 Mb. The change takes effect immediately but after a reboot, the original value is restored.

The other possibility is to change SHMMAX's default value in the kernel source (the relevant header file is /usr/src/linux/include/asm/shmparam.h if you have installed the source). In this case, you may also have to modify other parameters in the file, then rebuild the kernel. I suggest you do it only if you know what you are doing. For information on how to configure and compile the kernel see The Linux Kernel HOWTO (http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html) by Brian Ward.
Source: http://www.linux.com/base/ldp/howto/IngresII-HOWTO/sysreq.html

If I figure it out, I'll post it. I cannot imagine I am the only one with this problem... but maybe a newer distro could solve it?

[WildcardX]

I know openSUSE 10.3 doesnt have this problem. Actually its really not a "problem", its just a configuration. But if you are asking if there is a distro that doesnt need to have this configuration adjusted out of the box, then I know openSUSE 10.3 is one that doesn't need to be.

[cavedude]

Grandmaster items:

update items set slots = 2123776 where slots = 4220928;

[gernblan]

Can also put the command in your init script so that it gets changed at startup every time.

But who reboots a linux server anymore?

That's so... so... Windows. hehehehe

[cavedude]

Another option is to put it in the beginning of your EQEmu startup script, that's what I am doing and it works fine even after a reboot.

CVS was just updated, btw.

[sesmar]

I know this is referring to Sybase but this is a fix for shmat issues on Gentoo.


Sybase requires at least 64MB of system wide shared memory. Unfortunately, most linux distros, including Gentoo are configured with on 32MB, by default. To verify that your system has not been configured with more, issue the command /sbin/sysctl kernel.shmmax. If it doesn't report at least 64MB, or 67108864 bytes, then perform one of the following: - To temporarily increase the shared memory until next reboot issue the following: /sbin/sysctl -w kernel.shmmax=67108864 - To increase it permanently, edit /etc/sysctl.conf to include the following:

kernel.shmmax = 67108864

To make this take effect from now on issue a /sbin/sysctl -p.

[Angelox]

I know this is referring to Sybase but this is a fix for shmat issues on Gentoo.

This worked on my Mandriva too , thanks.

[gernblan]

Yup, will work on pretty much any distro