Linux 1.62.95577 alpha

[peppe 10]

Hi,

here Centos 6.3.3 64 bit. No way to run.

./server: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

[pchaxor 0]

marko;2201298']since when does finally have a stable version for linux out?

You are kidding right? This is an ALPHA .. does not even run on CentOS.. perhaps more flavors. Please READ the thread and come back and rethink your comment. LOL

---------- Post added at 11:16 ---------- Previous post was at 11:14 ----------

Well' date=' that's unfortunate.

In order to even test the new alpha, we (the 15thMEU Realism Unit) will need to reimage all of our servers (currently Centos 5.5) to support the required libraries to run the new server binary.

The new symbol requirements ( GLIBCXX_3.4.15 ) in libstdc++.so.6 are not supported in any current version of Centos or Redhat (even the 6.X versions). This will result in the requirement of completely reinstalling with either Ubuntu 12.04 to support the new server, or give up on Linux and install Windows (2003/2008/whatever). As our servers are remotely deployed, this will require a lot of extra effort. I'm not a programmer though. It might be possible to compile the required libraries and use an alternative LD_LIBRARY_PATH to satisfy the requirements of the new binary. If anyone has any well documented ways of accomplishing this, I would be very grateful if this information was made available to the community at large.

I'm ambivalent about the extra work. In any case, there are likely similar changes required to support the upcoming Arma 3 community alpha. This will be worthy work in the long term. It's just unfortunate that it needs to be done this late in the lifecycle of the Arma 2 series.

I'll be investigating alternatives before committing to any specific upgrade path at this time. That means that the 15thMEU public servers (and our private operational servers) will continue to be unavailable until we sort everything out.

With respect,

- 1stSgt Reite

First Sergeant

Echo Company HQ

15thMEU Realism Unit

Primary Server Administrator[/quote']

I just tested on CentOS 6.2 with latest updates on a box I have here...

WATCHDOG (6386): [sat Aug 4 11:05:33 EDT 2012] Starting server (port 2302)...

/home/arma2/server: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /home/arma2/server)

WATCHDOG (6386): [sat Aug 4 11:05:33 EDT 2012] Server died, waiting to restart...

I am postponing any deployments as well until I can figure out how to get it to run on CentOS. (I assume RedHat will have the same problems)

---------- Post added at 11:25 ---------- Previous post was at 11:16 ----------

Again .. THIS IS AN ALPHA, I even consider this "pre-alpha" ... based on Suma's post I think this honestly was a last ditch effort to get something out before the weekend to SILENCE us. HAHAHA!

I have to admit it kept me busy trying to figure out how to run it. I FAILED

I will wait for the actual ALPHA/Beta that will run on normal CentOS/RedHat Linux before I try again. Any further attempts are simply just a waste of time.

[JayC 0]

Getting crashes on the new alpha build, here is an example of the error:

*** glibc detected *** /home/tf88public2/arma2_162/server: free(): corrupted unsorted chunks: 0x42e2d288 ***

Global namespace not passed (script )

======= Backtrace: =========

/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xf744be42]

/home/tf88public2/arma2_162/server[0x8be1147]

/home/tf88public2/arma2_162/server[0x8bd5cc7]

/home/tf88public2/arma2_162/server[0x8bda082]

/home/tf88public2/arma2_162/server[0x8bda57f]

/home/tf88public2/arma2_162/server[0x87622cd]

/home/tf88public2/arma2_162/server[0x8762811]

/home/tf88public2/arma2_162/server[0x8762a73]

/home/tf88public2/arma2_162/server[0x84c22fc]

/home/tf88public2/arma2_162/server[0x84e5323]

/home/tf88public2/arma2_162/server[0x8a4f7d3]

/home/tf88public2/arma2_162/server[0x8a501c1]

/home/tf88public2/arma2_162/server[0x8081c95]

/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf73f14d3]

/home/tf88public2/arma2_162/server[0x8088521]

======= Memory map: ========

08048000-08f2a000 r-xp 00000000 08:01 18091105 /home/tf88public2/arma2_162/server

08f2a000-08f3b000 rw-p 00ee2000 08:01 18091105 /home/tf88public2/arma2_162/server

08f3b000-08f69000 rw-p 00000000 00:00 0

0a957000-4522a000 rw-p 00000000 00:00 0 [heap]

f364c000-f5300000 rw-p 00000000 00:00 0

f5300000-f5400000 rw-p 00000000 00:00 0

f54ff000-f5500000 ---p 00000000 00:00 0

f5500000-f5d00000 rw-p 00000000 00:00 0

f5d00000-f5db2000 rw-p 00000000 00:00 0

f5db2000-f5e00000 ---p 00000000 00:00 0

f5eff000-f5f00000 ---p 00000000 00:00 0

f5f00000-f6700000 rw-p 00000000 00:00 0

f6700000-f6721000 rw-p 00000000 00:00 0

f6721000-f6800000 ---p 00000000 00:00 0

f68ff000-f6900000 ---p 00000000 00:00 0

f6900000-f7100000 rw-p 00000000 00:00 0

f7100000-f7121000 rw-p 00000000 00:00 0

f7121000-f7200000 ---p 00000000 00:00 0

f722a000-f723d000 r-xp 00000000 08:01 9834195 /lib/i386-linux-gnu/libresolv-2.15.so

f723d000-f723e000 ---p 00013000 08:01 9834195 /lib/i386-linux-gnu/libresolv-2.15.so

f723e000-f723f000 r--p 00013000 08:01 9834195 /lib/i386-linux-gnu/libresolv-2.15.so

f723f000-f7240000 rw-p 00014000 08:01 9834195 /lib/i386-linux-gnu/libresolv-2.15.so

f7240000-f7242000 rw-p 00000000 00:00 0

f7242000-f724d000 r-xp 00000000 08:01 9834189 /lib/i386-linux-gnu/libnss_files-2.15.so

f724d000-f724e000 r--p 0000a000 08:01 9834189 /lib/i386-linux-gnu/libnss_files-2.15.so

f724e000-f724f000 rw-p 0000b000 08:01 9834189 /lib/i386-linux-gnu/libnss_files-2.15.so

f7252000-f7253000 ---p 00000000 00:00 0

f7253000-f72c3000 rw-p 00000000 00:00 0

f72c3000-f72c4000 ---p 00000000 00:00 0

f72c4000-f73d8000 rw-p 00000000 00:00 0

f73d8000-f7577000 r-xp 00000000 08:01 9834180 /lib/i386-linux-gnu/libc-2.15.so

f7577000-f7579000 r--p 0019f000 08:01 9834180 /lib/i386-linux-gnu/libc-2.15.so

f7579000-f757a000 rw-p 001a1000 08:01 9834180 /lib/i386-linux-gnu/libc-2.15.so

f757a000-f757d000 rw-p 00000000 00:00 0

f757d000-f7599000 r-xp 00000000 08:01 9834176 /lib/i386-linux-gnu/libgcc_s.so.1

f7599000-f759a000 r--p 0001b000 08:01 9834176 /lib/i386-linux-gnu/libgcc_s.so.1

f759a000-f759b000 rw-p 0001c000 08:01 9834176 /lib/i386-linux-gnu/libgcc_s.so.1

f759b000-f75a2000 r-xp 00000000 08:01 9834196 /lib/i386-linux-gnu/librt-2.15.so

f75a2000-f75a3000 r--p 00006000 08:01 9834196 /lib/i386-linux-gnu/librt-2.15.so

f75a3000-f75a4000 rw-p 00007000 08:01 9834196 /lib/i386-linux-gnu/librt-2.15.so

f75a4000-f75a7000 r-xp 00000000 08:01 9834183 /lib/i386-linux-gnu/libdl-2.15.so

f75a7000-f75a8000 r--p 00002000 08:01 9834183 /lib/i386-linux-gnu/libdl-2.15.so

f75a8000-f75a9000 rw-p 00003000 08:01 9834183 /lib/i386-linux-gnu/libdl-2.15.so

f75a9000-f75c0000 r-xp 00000000 08:01 9834194 /lib/i386-linux-gnu/libpthread-2.15.so

f75c0000-f75c1000 r--p 00016000 08:01 9834194 /lib/i386-linux-gnu/libpthread-2.15.so

f75c1000-f75c2000 rw-p 00017000 08:01 9834194 /lib/i386-linux-gnu/libpthread-2.15.so

f75c2000-f75c5000 rw-p 00000000 00:00 0

f75c5000-f75ef000 r-xp 00000000 08:01 9834184 /lib/i386-linux-gnu/libm-2.15.so

f75ef000-f75f0000 r--p 00029000 08:01 9834184 /lib/i386-linux-gnu/libm-2.15.so

f75f0000-f75f1000 rw-p 0002a000 08:01 9834184 /lib/i386-linux-gnu/libm-2.15.so

f75f1000-f76c9000 r-xp 00000000 08:01 22942219 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f76c9000-f76ca000 ---p 000d8000 08:01 22942219 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f76ca000-f76ce000 r--p 000d8000 08:01 22942219 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f76ce000-f76cf000 rw-p 000dc000 08:01 22942219 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f76cf000-f76d6000 rw-p 00000000 00:00 0

f76dd000-f76de000 rw-p 00000000 00:00 0

f76de000-f76e3000 r-xp 00000000 08:01 9834188 /lib/i386-linux-gnu/libnss_dns-2.15.so

f76e3000-f76e4000 r--p 00004000 08:01 9834188 /lib/i386-linux-gnu/libnss_dns-2.15.so

f76e4000-f76e5000 rw-p 00005000 08:01 9834188 /lib/i386-linux-gnu/libnss_dns-2.15.so

f76e5000-f76e6000 rw-p 00000000 00:00 0

f76e6000-f76e7000 ---p 00000000 00:00 0

f76e7000-f76ec000 rw-p 00000000 00:00 0

f76ec000-f76ed000 r-xp 00000000 00:00 0 [vdso]

f76ed000-f770d000 r-xp 00000000 08:01 9834177 /lib/i386-linux-gnu/ld-2.15.so

f770d000-f770e000 r--p 0001f000 08:01 9834177 /lib/i386-linux-gnu/ld-2.15.so

f770e000-f770f000 rw-p 00020000 08:01 9834177 /lib/i386-linux-gnu/ld-2.15.so

ffdda000-ffe05000 rw-p 00000000 00:00 0 [stack]

Hope this helps in troubleshooting.

---------- Post added at 15:44 ---------- Previous post was at 15:27 ----------

Hi,

here Centos 6.3.3 64 bit. No way to run.

./server: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

Do you have the 32bit libs installed?

[Kindling 1]

I'm not sure this is accurate. I tried this test, and I got 0, and then I installed the 1.62 server and it appears to be working just fine (Stock standard Ubuntu 11.04), except that on some (not all) missions, about 3 or 4 seconds into the game, there is a yellow chain, then a red chain, and it appears to crash and restart. Perhaps someone can help me find some useful logs for this. The log.2302.txt file doesn't seem to shed any light on why its crashing. I admit, there are several mods running, and it doesn't do this on all the missions, but is there a way to check whether its a mod doing the crashing or something else. (Other than uninstalling all the mods.. that would be pointless, because the missions wouldn't start at all without the mods...)

Are you sure you were checking the strings in the correct file? Perhaps it's in /usr/glibc or /usr/lib for you? Remember you're checking the 32bit library. Try 'grep GLIBC' instead - you should get a list of versions. Make sure to check strings on libstdc++.so.6, not .so.5.

The best way to track the crashes is to run the server under screen - that way you get all the output to the terminal but you can still detach if needed. There are several known issues already with this build, though. It is, of course, rushed at the behest of us Linux admins :)

And peppe, may need to yum install libstdc++ or similar.

JayC, this is a very common issue at the moment :)

pchaxor, you're going to need to update whether you like it or not - it's compiled with a new version of glibc, anything older simply will not work and upgrading glibc and libstdc++ when your userland is linked to the older version is practically server suicide. There are ways to upgrade without rebooting, if that's too much hassle for you - look up installing distros via chroot. Trust me, better the server is updated for new libs now than not having the time to after ARMA 2's release cycle (in the days of ARMA 3) and nobody being able to run a Linux binary server after distros catch up.

Edited August 4, 2012 by Kindling

[peppe 10]

Getting crashes on the new alpha build, here is an example of the error:

Hope this helps in troubleshooting.

---------- Post added at 15:44 ---------- Previous post was at 15:27 ----------

Do you have the 32bit libs installed?

Hello,

not I havent. Must I have?

tnx for reply

[Kindling 1]

Hello,

not I havent. Must I have?

tnx for reply

The server is 32bit, it requires 32bit libraries (eg. on an amd64 system you must be multiarch, read readme.txt).

[peppe 10]

The server is 32bit, it requires 32bit libraries (eg. on an amd64 system you must be multiarch, read readme.txt).

Hello,

I'm running a Intel i7. I think is better to install a 32 bit version of centos (or not?) :)

Tnx for your time

[imago 1]

arma2oaserver-162-95577 crashes repeatedly on a populated Linux server 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux.

Thanks BIS!

[Dwarden 1125]

btw. all linux admins are welcome to skype channel for Linux dedicated server listed here http://forums.bistudio.com/showthread.php?131825-Skype-groups-amp-other-contact-groups

especially if you seek solutions to problems, colaborative effort gives quite good results so far

[Kindling 1]

arma2oaserver-162-95577 crashes repeatedly on a populated Linux server 3.2.0-27-generic #43-Ubuntu SMP Fri Jul 6 14:25:57 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux.

Thanks BIS!

Hence why it clearly says 'alpha'. It's in no way a production-quality build. Provide your crash dumps so the dev team can fix the issues :)

peppe, personally I'd install 64bit/multiarch but if you're just running the ARMA II server there should be no real difference. I'd really also suggest going for Fedora or Debian Wheezy over CentOS for now as several people have claimed that the CentOS glibc builds are out of date and can't run the server application.

[pchaxor 0]

Yeah instead of waiting for BIS devs to fix the issues with CentOS and RedHat use something that works with an alpha build that crashes when the server is populated.

Kindling, really I know you are trying to be helpful but is this honestly good advice? I am not troll'n but let's be realistic here ... take a poll how many people using RedHat or CentOS as their server?

Debian is pretty good I have to admit, but isnt that having issues also? Any suggestions on what Linux flavor to use should simply be thwarted until something a bit more solid happens. no?

My advice at this point would be... If you NEED a server up right NOW, use Windows or WINE if you can. The support for Linux is just not there at this point, and unless something changes in BIS development it wont ever be "fully supported" on the same level as Windows is.

---------- Post added at 17:03 ---------- Previous post was at 16:57 ----------

I think what I am going to do is WAIT and let the BIS devs tell me what flavor works best with their server. I think that is good advice at this point.

Edited August 4, 2012 by pchaxor

[JayC 0]

Hello,

I'm running a Intel i7. I think is better to install a 32 bit version of centos (or not?) :)

Tnx for your time

You can install the 64 bit version of Linux, just make sure you also install 32bit libs as well. What flavor of Linux are you running?

Edited August 4, 2012 by JayC

[imago 1]

Provide your crash dumps so the dev team can fix the issues

wait what? the crash dumps don't automatically upload themselves to BIS specially trained linux dev team via skype?

[mons00n 3]

Just booted my server up. I was able to connect and load a map. As soon as I dropped into the game I get this error:

*** glibc detected *** /home/bob/local/arma2/server: corrupted double-linked list: 0x3ed03c30 ***

after which I got no response from the server...and eventually a blue screen on my desktop.

I reloaded the server with no mods and everything 'seemed' ok besides the unusually long sync time. I'll do some more experimenting and report back.

ubuntu 12.04 64bit

EDIT: the above problem seems to only occur when ACE is enabled (latest version). I'm also getting this error in regards to my config file regardless of what mods are enabled:

Warning Message: Preprocessor failed on file configit.cfg - error 7.

Edited August 4, 2012 by mons00n

[JayC 0]

pchaxor,

Clearly you're not understanding the issue... CentOS does not have the correct version of base glibc installed. It's like not having the correct version of .net framework installed (but even more base level than that)... Unless BIS changes their build system to a older version of Linux which doesn't have GLIBC 2.7 (and since they appear to be using a very new version of glibc my guess is they can't revert to an older version) then a standard install of CentOS is not going to work, it's not a BUG that they're going to fix in the next release, it's a base code requirement of the new build that is not likely to change.

CentOS 5.x is never going to work with GLIBC 2.7

CentOS 6.x may support the correct version at some later date - best case 4 to 6 months from now as RedHat hasn't even started back porting the current version per their website.

CentOS 7.x should support - Likely more than 24-36 months away at least

Because everything on the system uses glibc there is no 'easy fix' to upgrade to the correct version.

You could *maybe* used chroot as mentioned above... you could use virtualization or emulation.

But, unless BIS changes their build system RHEL and all it's forks are not going to work with new linux server builds out of the box.

And I feel your pain, I run a ton of CentOS and RHEL systems, and love it as a very stable enterprise grade Linux distro... Clearly their are using a debian 'unstable' based distro of some sort as the build system (unstable as in the technical branch name not in the real stability of the OS) because as posted above it's a debian based system and only the 'unstable' branch contains this new of a version of glibc. This is why Ubuntu (also based on debian unstable) is working with no glibc issues.

I'm not suggesting you make a move now, it's probably a good idea to take a wait and see approach since this is a VERY unstable alpha of a server right now. But, you (and other CentOS sys admins) need to understand that unless BIS can and do change to an older version of glibc on their build system - highly unlikely, that CentOS 5 is never going to work, and CentOS 6 best case will not work for months if ever.

As for your suggestion to wait for BIS to tell you what distro of Linux they recommend in a way they have, it's a debian based distro with glibc 2.7 on it, which is the 'Sid' or Ubuntu 11+ at this point to name some of the more popular ones.

Yeah instead of waiting for BIS devs to fix the issues with CentOS and RedHat use something that works with an alpha build that crashes when the server is populated.

Kindling, really I know you are trying to be helpful but is this honestly good advice? I am not troll'n but let's be realistic here ... take a poll how many people using RedHat or CentOS as their server?

Debian is pretty good I have to admit, but isnt that having issues also? Any suggestions on what Linux flavor to use should simply be thwarted until something a bit more solid happens. no?

My advice at this point would be... If you NEED a server up right NOW, use Windows or WINE if you can. The support for Linux is just not there at this point, and unless something changes in BIS development it wont ever be "fully supported" on the same level as Windows is.

---------- Post added at 17:03 ---------- Previous post was at 16:57 ----------

I think what I am going to do is WAIT and let the BIS devs tell me what flavor works best with their server. I think that is good advice at this point.

---------- Post added at 22:18 ---------- Previous post was at 22:03 ----------

Just booted my server up. I was able to connect and load a map. As soon as I dropped into the game I get this error:

after which I got no response from the server...and eventually a blue screen on my desktop.

I reloaded the server with no mods and everything 'seemed' ok besides the unusually long sync time. I'll do some more experimenting and report back.

ubuntu 12.04 64bit

I'm seeing this error from time to time as well, it appears to be a 'bug' in the alpha build of the dedicated server, the only way to fix from this error is to kill -9 pid the watchdog AND the server processes and re-run it.

But, expect it to crash again.

Edited August 4, 2012 by JayC

[mons00n 3]

---------- Post added at 22:18 ---------- Previous post was at 22:03 ----------

I'm seeing this error from time to time as well, it appears to be a 'bug' in the alpha build of the dedicated server, the only way to fix from this error is to kill -9 pid the watchdog AND the server processes and re-run it.

But, expect it to crash again.

Yea I've only seen that bug occur when ACE was loaded though...not sure if it's something with that specific mod. Right now I can't get the config to load, I get

Warning Message: Preprocessor failed on file configit.cfg - error 7.

Warning Message: Preprocessor failed on file configit.cfg - error 7.

Warning Message: Preprocessor failed on file configit.cfg - error 7.

Warning Message: Preprocessor failed on file configit.cfg - error 7.

The server still starts, but none of the configuration from the config file is used. So the server name/join password/etc etc doesn't load up as expected.

EDIT: nevermind! got that error even when ACE wasn't loaded. Here's a dump from the terminal window:

bob@Newton:~/local/arma2$ *** glibc detected *** /home/bob/local/arma2/server: free(): corrupted unsorted chunks: 0x30a24cd8 ***

======= Backtrace: =========

/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0xf74f2e42]

/home/bob/local/arma2/server[0x8114feb]

/home/bob/local/arma2/server[0x8bc3031]

/home/bob/local/arma2/server[0x8bdf896]

/home/bob/local/arma2/server[0x8bd5cc7]

/home/bob/local/arma2/server[0x8be2c8d]

/home/bob/local/arma2/server[0x84c2281]

/home/bob/local/arma2/server[0x84e5323]

/home/bob/local/arma2/server[0x8a4f7d3]

/home/bob/local/arma2/server[0x8a501c1]

/home/bob/local/arma2/server[0x8081c95]

/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf74984d3]

/home/bob/local/arma2/server[0x8088521]

======= Memory map: ========

08048000-08f2a000 r-xp 00000000 08:21 1848757 /home/bob/local/arma2/server

08f2a000-08f3b000 rw-p 00ee2000 08:21 1848757 /home/bob/local/arma2/server

08f3b000-08f69000 rw-p 00000000 00:00 0

0a3e7000-1a875000 rw-p 00000000 00:00 0 [heap]

1a875000-1a876000 rwxp 00000000 00:00 0 [heap]

1a876000-30b83000 rw-p 00000000 00:00 0 [heap]

f3200000-f326f000 rw-p 00000000 00:00 0

f326f000-f3300000 ---p 00000000 00:00 0

f3400000-f3444000 rw-p 00000000 00:00 0

f3444000-f3500000 ---p 00000000 00:00 0

f3597000-f55ff000 rw-p 00000000 00:00 0

f55ff000-f5600000 ---p 00000000 00:00 0

f5600000-f5e00000 rw-p 00000000 00:00 0

f5e00000-f5e49000 rw-p 00000000 00:00 0

f5e49000-f5f00000 ---p 00000000 00:00 0

f5fff000-f6000000 ---p 00000000 00:00 0

f6000000-f6800000 rw-p 00000000 00:00 0

f6800000-f6821000 rw-p 00000000 00:00 0

f6821000-f6900000 ---p 00000000 00:00 0

f699f000-f69b9000 r-xp 00000000 08:21 1851259 /home/bob/local/arma2/expansion/battleye/beserver.so

f69b9000-f69bc000 rw-p 00019000 08:21 1851259 /home/bob/local/arma2/expansion/battleye/beserver.so

f69bc000-f69e7000 rw-p 00000000 00:00 0

f69e7000-f69fa000 r-xp 00000000 08:21 2760563 /lib/i386-linux-gnu/libresolv-2.15.so

f69fa000-f69fb000 ---p 00013000 08:21 2760563 /lib/i386-linux-gnu/libresolv-2.15.so

f69fb000-f69fc000 r--p 00013000 08:21 2760563 /lib/i386-linux-gnu/libresolv-2.15.so

f69fc000-f69fd000 rw-p 00014000 08:21 2760563 /lib/i386-linux-gnu/libresolv-2.15.so

f69fd000-f69ff000 rw-p 00000000 00:00 0

f69ff000-f6a00000 ---p 00000000 00:00 0

f6a00000-f7200000 rw-p 00000000 00:00 0

f7200000-f7221000 rw-p 00000000 00:00 0

f7221000-f7300000 ---p 00000000 00:00 0

f730e000-f7313000 r-xp 00000000 08:21 2760535 /lib/i386-linux-gnu/libnss_dns-2.15.so

f7313000-f7314000 r--p 00004000 08:21 2760535 /lib/i386-linux-gnu/libnss_dns-2.15.so

f7314000-f7315000 rw-p 00005000 08:21 2760535 /lib/i386-linux-gnu/libnss_dns-2.15.so

f7315000-f7320000 r-xp 00000000 08:21 2760539 /lib/i386-linux-gnu/libnss_files-2.15.so

f7320000-f7321000 r--p 0000a000 08:21 2760539 /lib/i386-linux-gnu/libnss_files-2.15.so

f7321000-f7322000 rw-p 0000b000 08:21 2760539 /lib/i386-linux-gnu/libnss_files-2.15.so

f736a000-f736b000 ---p 00000000 00:00 0

f736b000-f747f000 rw-p 00000000 00:00 0

f747f000-f761e000 r-xp 00000000 08:21 2760503 /lib/i386-linux-gnu/libc-2.15.so

f761e000-f7620000 r--p 0019f000 08:21 2760503 /lib/i386-linux-gnu/libc-2.15.so

f7620000-f7621000 rw-p 001a1000 08:21 2760503 /lib/i386-linux-gnu/libc-2.15.so

f7621000-f7624000 rw-p 00000000 00:00 0

f7624000-f7640000 r-xp 00000000 08:21 2760487 /lib/i386-linux-gnu/libgcc_s.so.1

f7640000-f7641000 r--p 0001b000 08:21 2760487 /lib/i386-linux-gnu/libgcc_s.so.1

f7641000-f7642000 rw-p 0001c000 08:21 2760487 /lib/i386-linux-gnu/libgcc_s.so.1

f7642000-f7649000 r-xp 00000000 08:21 2760567 /lib/i386-linux-gnu/librt-2.15.so

f7649000-f764a000 r--p 00006000 08:21 2760567 /lib/i386-linux-gnu/librt-2.15.so

f764a000-f764b000 rw-p 00007000 08:21 2760567 /lib/i386-linux-gnu/librt-2.15.so

f764b000-f764e000 r-xp 00000000 08:21 2760515 /lib/i386-linux-gnu/libdl-2.15.so

f764e000-f764f000 r--p 00002000 08:21 2760515 /lib/i386-linux-gnu/libdl-2.15.so

f764f000-f7650000 rw-p 00003000 08:21 2760515 /lib/i386-linux-gnu/libdl-2.15.so

f7650000-f765d000 r-xp 00000000 08:21 2760559 /lib/i386-linux-gnu/libpthread-2.15.so

f765d000-f765e000 rwxp 0000d000 08:21 2760559 /lib/i386-linux-gnu/libpthread-2.15.so

f765e000-f7667000 r-xp 0000e000 08:21 2760559 /lib/i386-linux-gnu/libpthread-2.15.so

f7667000-f7668000 r--p 00016000 08:21 2760559 /lib/i386-linux-gnu/libpthread-2.15.so

f7668000-f7669000 rw-p 00017000 08:21 2760559 /lib/i386-linux-gnu/libpthread-2.15.so

f7669000-f766c000 rw-p 00000000 00:00 0

f766c000-f7696000 r-xp 00000000 08:21 2760519 /lib/i386-linux-gnu/libm-2.15.so

f7696000-f7697000 r--p 00029000 08:21 2760519 /lib/i386-linux-gnu/libm-2.15.so

f7697000-f7698000 rw-p 0002a000 08:21 2760519 /lib/i386-linux-gnu/libm-2.15.so

f7698000-f7770000 r-xp 00000000 08:21 2761298 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f7770000-f7771000 ---p 000d8000 08:21 2761298 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f7771000-f7775000 r--p 000d8000 08:21 2761298 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f7775000-f7776000 rw-p 000dc000 08:21 2761298 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.16

f7776000-f777d000 rw-p 00000000 00:00 0

f777e000-f7780000 rw-p 00000000 00:00 0

f7780000-f7781000 ---p 00000000 00:00 0

f7781000-f7791000 rw-p 00000000 00:00 0

f7791000-f7792000 ---p 00000000 00:00 0

f7792000-f7797000 rw-p 00000000 00:00 0

f7797000-f7798000 r-xp 00000000 00:00 0 [vdso]

f7798000-f77b8000 r-xp 00000000 08:21 2760491 /lib/i386-linux-gnu/ld-2.15.so

f77b8000-f77b9000 r--p 0001f000 08:21 2760491 /lib/i386-linux-gnu/ld-2.15.so

f77b9000-f77ba000 rw-p 00020000 08:21 2760491 /lib/i386-linux-gnu/ld-2.15.so

ff7da000-ff807000 rw-p 00000000 00:00 0 [stack]

Edited August 4, 2012 by mons00n

[pchaxor 0]

@JayC .. Thanks for the detailed explanation. I do now understand very well and I guess I am hoping that BIS will back down from using the GLIBC 2.7 and find another way. If not they are going to simply lose a ton of CentOS/RedHat Linux servers. Our unit is already considering dumping Linux and simply going with Windows just so we can actually have a fully functional/supported server and not have to go through this with ArmA3. (you know it will happen) It puzzles me why a developer would put themselves in a position to have to use a library that is not fully supported by a majority of the rpm platforms and forcing Linux admins to trade their "stability for features" because they failed to develop the product along side of the windows platform. Ok, I am starting to rant so I am going to end my post here.

Thanks for the info. Much appreciated.

I have faith that BIS will find a way to make it work; I am just going to continue to be patient and see what happens.

[JayC 0]

@JayC .. Thanks for the detailed explanation. I do now understand very well and I guess I am hoping that BIS will back down from using the GLIBC 2.7 and find another way. If not they are going to simply lose a ton of CentOS/RedHat Linux servers. Our unit is already considering dumping Linux and simply going with Windows just so we can actually have a fully functional/supported server and not have to go through this with ArmA3. (you know it will happen) It puzzles me why a developer would put themselves in a position to have to use a library that is not fully supported by a majority of the rpm platforms and forcing Linux admins to trade their "stability for features" because they failed to develop the product along side of the windows platform. Ok, I am starting to rant so I am going to end my post here.

Thanks for the info. Much appreciated.

I have faith that BIS will find a way to make it work; I am just going to continue to be patient and see what happens.

Well, I don't think they upgraded to glibc 2.7 for the fun of it... I suspect as the dev said there is a library they are using which requires it, or at the very least some other function found in that version of gcc. I understand the desire to go to windows, but keep in mind you're looking at a 10-15% performance hit, which would lower your numbers from 40 players down to 34-36 players on the exact same hardware. This really starts to become a major problem for large clans/teams because of the design of ArmA2's dedicated server where most of the CPU processing happens on a single core, which means single core speed is critical for large scale operations. We're currently running a E3-1230V2 in our server, which is a pretty top of the line cpu, and would have to go to an E3-1280V2 or E3-1290V2 to get the same performance under Windows, which moves from a $225 proc to a $650 to $850 proc. Hopefully they will better support more cores on the dedicated server in ArmA3 or we're going to see serious problems in the ability of large teams/cans to host events.

Fedora which is basically the unstable branch of RHEL should run this alpha, again I don't think they're picking this just because, I suspect the new library they're using has very specific requirements. You have to remember that RHEL and CentOS are designed to be stable enterprise operating systems with a 8-10 year life span, that drastically limits your ability to use new types of libraries and features, but in an enterprise environment that isn't a critical feature set, where you want long term business applications to run without crashing.

Truth is Ubuntu 12 is stable, enough to run production apps on, but they will end of life support much sooner for it, in the next 2 to 3 years forcing a shorter term upgrade path.

Since it appears it took them 3+ weeks to get the new build system in place, and the fact they should have known the issues that would be caused by the selection of distro/branch, that they are going to make any significant changes. My guess is something in the new version requires a new(er) library and required the upgrade to the new build system, and likely they will be unable to provide pre-glibc 2.7 support because of that dependency. But that is pure conjecture on my part.

BTW, para-vm would be a good stop gap measure, this will only have a 2-5% performance hit, and allow you to run ubuntu or debian on centos 5.x, and have glibc 2.7 support.

Edited August 5, 2012 by JayC

[PELHAM 10]

Truth is Ubuntu 12 is stable, enough to run production apps on, but they will end of life support much sooner for it, in the next 2 to 3 years forcing a shorter term upgrade path.

Starting with Ubuntu 12.04 LTS, both server and desktop receive 5 years support,

[JayC 0]

Starting with Ubuntu 12.04 LTS, both server and desktop receive 5 years support,

I stand corrected, but still shorter than the 10 years on RHEL and CentOS.

[sthalik 10]

Guys,

You're speaking as if changing libc/libstdc++ was hard or even required root privileges.

Devs, thank you very much for the build and continued support of UNIX operating systems. I'll try it with proper-version libraries soonish and see if there are indeed any errors (double free(), heap corruption or somesuch).

In case anyone wonders, play with the dynamic linker (ld-linux.so.whatnot), LD_PRELOAD, LD_LIBRARY_PATH or just chroot it (might indeed require root privileges). The latter seems preferable on a multi-user system anyway.

Edited August 5, 2012 by sthalik

[peppe 10]

Hence why it clearly says 'alpha'. It's in no way a production-quality build. Provide your crash dumps so the dev team can fix the issues :)

peppe, personally I'd install 64bit/multiarch but if you're just running the ARMA II server there should be no real difference. I'd really also suggest going for Fedora or Debian Wheezy over CentOS for now as several people have claimed that the CentOS glibc builds are out of date and can't run the server application.

Hello,

my centos is noarch, I think I wait a little for a stable code and centos upgraded libs.

Thanks Kind... you are very kind ;)

---------- Post added at 10:25 AM ---------- Previous post was at 10:22 AM ----------

Hello Jay

Centos 6.3.3 64 bit

(I've voted in the poll)

Edited August 5, 2012 by peppe

[pchaxor 0]

Guys,

You're speaking as if changing libc/libstdc++ was hard or even required root privileges.

Devs, thank you very much for the build and continued support of UNIX operating systems. I'll try it with proper-version libraries soonish and see if there are indeed any errors (double free(), heap corruption or somesuch).

In case anyone wonders, play with the dynamic linker (ld-linux.so.whatnot), LD_PRELOAD, LD_LIBRARY_PATH or just chroot it (might indeed require root privileges). The latter seems preferable on a multi-user system anyway.

really? You can just swap out the core libraries like it's nothing and don't even need root privs? teach us master. :) This I would like to see on YouTube if you can make it happen. That would be a feat for sure. Please try using RedHat or CentOS and see how far you get. (I don't recommend doing this on a production system)

[sthalik 10]

arma ~% id
uid=1001(arma) gid=1001(arma) groups=1001(arma)
arma ~% /lib32/ld-linux.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
[...]
 --list                list all dependencies and how they are resolved
 --verify              verify that given object really is a dynamically linked
                       object we can handle
[b][color="#FF0000"] --library-path[/color][/b] PATH   use given PATH instead of content of the environment
                       variable LD_LIBRARY_PATH
[b][color="#FF0000"] --inhibit-rpath[/color][/b] LIST  ignore RUNPATH and RPATH information in object names
                       in LIST
 --audit LIST          use objects named in LIST as auditors

This would be a start.

Personally I use a chroot, since forever. That doesn't mean that a chroot is required.

bin:
server

etc:
group  hosts  ld.so.cache  localtime  nsswitch.conf  passwd  protocols  resolv.conf  services

lib:
ld-2.13.so     libc.so.6      libgcc_s.so.1  libnss_dns-2.13.so  libpthread.so.0    librt.so.1           libz.so.1
ld-linux.so.2  libdl-2.13.so  libm-2.13.so   libnss_dns.so.2     libresolv-2.13.so  libstdc++.so.6       libz.so.1.2.7
libc-2.13.so   libdl.so.2     libm.so.6      libpthread-2.13.so  libresolv.so.2     libstdc++.so.6.0.17

Edited August 5, 2012 by sthalik

[Kindling 1]

mons00n, that's a known error. Keep track of the missions it's caused on and let the devs know.

JayC's pretty much spot on on the fact that you can't simply 'upgrade glibc'. I'd add that the reasoning behind this - aside from required library updates - is likely that this means less work will need to be done when ARMA II: CO approaches EOL. As it was, the linked glibc wouldn't have survived the next few years - you would have been unable to run the server application on current Linux distro installations. It's a good, forward-thinking move that will allow admins to host ARMA II servers well into the future.

Not to mention the fact that you should probably upgrade soon anyway, if not for the features then for the new stability and security fixes that are always being introduced.

It's entirely possible to use a chroot. I wouldn't suggest using LD_PRELOAD or similar unless you're fairly experienced, as you'd need to build pretty much all of the deps for the server app with a new, seperate glibc ontop of staying up-to-date with security fixes. Bulding libc and libstd++ is generally a task reserved for distro maintainers or source-based distro users who tend to be more experienced with these matters.