killswitch

I'll echo what MaSSive said: don't run the A2 game servers as the root user. Create a new, normal user account for that. Now, regarding your "Segmentation fault" error. Seeing as how you're using CentOS, it is possible that SELinux is the culprit. See my post #4 in this thread: Linux-ArmA-and-Servers-Oh-my. The short version is: if SELinux is in enforcing mode (and it should be), re-label the Arma server executables to allow them to use BattlEye: chcon -t java_exec_t /home/games/arma2/server /home/games/arma2oa/server You can remove the folder /home/games/arma2/BattlEye since you already have the lower-case variant named "battleye" with beserver.so in it.

For some reason you are using a modified start script that doesn't use "OTHERPARAMS" to add the -mod=... startup parameter there. Now, to fix your variant of the script, change this: MODS=-"mod ${ARMA_DIR}/@cba;${ARMA_DIR}/@cba_a2;@cba_oa;@ace;@acex;@acex_ru;@acex_sm;@acex_usnavy;@i44;@lingor;@namalsk;@thirsk;@wintercamos;" into MODS="-mod=@cba;@cba_a2;@cba_oa;@ace;@acex;@acex_ru;@acex_sm;@acex_usnavy;@i44;@lingor;@namalsk;@thirsk;@wintercamos" and ${SERVER} >>${LOGFILE} 2>>${LOGFILE} -server -config=${CONFIG} -port=${PORT} -pid=${PIDFILE} ${OTHERPARAMS} \"${MODS}\" into ${SERVER} >>${LOGFILE} 2>>${LOGFILE} -server -config=${CONFIG} -port=${PORT} -pid=${PIDFILE} ${OTHERPARAMS} ${MODS}

You wrote that the cpu is a Xeon E3120, which is a dual core Core 2 Duo architecture processor from back in the year 2007 and it doesn't have hyperthreading. On the other hand, you mention that you "have better hardware than other hosts" and that HTT is enabled in the BIOS so I'm suspecting that it's not an E3120. Is it actually a contemporary Sandy Bridge-based Xeon E3-1230? (3.2 GHz, 4 cores plus hyperthreading) Yes, try disabling HyperThreading in the BIOS and see if it makes a difference. Regarding -exThreads try it with no -exThreads parameter. These days, I believe the ArmA II dedi is good at auto-detecting a suitable value. Experiment with setting the core affinity for the ArmA II server and see if it helps. Does it "normally improve performance"? *shrug* Not in my experience. As for good configs for the min/max bandwidth... search through this forum and you'll see many discussions on that subject over the years. You might find a setting that has worked well for others that'll do the same for you. Good luck! :)

CentOS? ArmA II server keeps restarting? Lots of files named core.XXXXX being created? Yep, I have a sneaky suspicion. :-) Try disabling BattlEye in the server.cfg for a moment and restart the ArmA II server. If that solves the continously restarting server issue, the problem is most likely SELinux being in the enforcing state. It will notice BE doing something that's not allowed by the default SELinux policies and thus prevents the server from running. This then leads to a crash, wich causes the core dump files ("core.XXXXX") you are seeing. Should this be the case, that is, disabling BattlEye in the config lets you start the server, try setting SELinux into permissive mode and try the ArmA II server again (with BattlEye enabled again).So, how do you switch SELinux between different modes? Say hello to the setenforce command. As root, run setenforce 0 This will put SELinux in permissive mode until the next reboot. Enable BattlEye in the server.cfg again and try running the game server again. You can then set it back to enforcing mode after the gaming session using setenforce 1 (as root) afterwards. Now, we have a bit of a Catch-22. You want SELinux for protection, but you also want to be able to use BattlEye for your ArmA II game server. How to keep SELinux enabled (enforcing), yet allow the ArmA II server and BattlEye to do their thing? Short of creating a custom SELinux policy for the ArmA II server, you could make use of an existing security context type that will allow this. As root, set the SELinux file type to java_exec_t for the dedicated server executable ("server"): chcon -t java_exec_t /path/to/arma2/server Also, you should make sure you don't have the PMC or BAF mod folders on the server. They are not needed and having them there will cause errors.

These two issues are still present: Bug #17313: [Linux DS] Date format wrong Bug #23261: Linux server strips the first slash on some command line options, at least -cfg/-config

That's apparently an old issue - absolute paths do not work with the -cfg and -config launch parameters. It's reported here: Linux server strips the first slash on some command line options, at least -cfg/-config. Possible workaround: keep the configs in the server installation directory, but rename them to something odd/cryptic/secret. NOTE: -bepath=... works fine with an absolute path

It does support ArmA II, but you'll have to tell GameQ to use the challenge-response variant of the query protocol, which GameQ calls "gamespy3".Here's how you can do it: first, edit the games.ini file and add a new game identifier for ArmA II. Let's call it "arma2": [arma2] name = "ArmA II" port = 2302 prot = "gamespy3" Then you can use that in the example.php file like this. In my testing, I had to increase the timeout as well: ... ... // Define your servers, // see list.php for all supported games and identifiers. $servers = array( 'My ArmA II server ' => array('arma2', 'aaa.bbb.ccc.ddd') //'server 1' => array('quake3', '194.109.69.61'), //'server 2' => array('cssource', '194.109.69.51', 27015), //'server 3' => array('bf2142', '194.109.69.21'), //'server 4' => array('ts3', 'voice.planetteamspeak.com') ); ... ... // You can optionally specify some settings $gq->setOption('timeout', 2000); (I've tested and verified that it works with GameQ 1.12) Hope that helps!

Ok. Now head back to post #11 in this thread and follow the instructions there - you need to edit the start script (arma2oaserver) to load the beta game data. (This is what MadDogX means by "run the server with the beta modline")

The errors you guys are seeing are due to the 82416 build needing certain post-1.59 config items that aren't there in the official 1.59 game files. They are however present in the betas. Therefore, to make it work on your Linux server, you need the Windows beta data files aswell - that is to say the the X:\Path\To\ArmA 2\Expansion\beta folder from your Windows machine. Upload the "Expansion\beta" folder from your Windows machine to the Linux server and place it in the "/path/to/arma2/expansion" directory. The result is the directory "/path/to/arma2/expansion/beta" Open the start script "arma2oaserver" and change the OTHERPARAMS line to something like:OTHERPARAMS='-cpucount=2 -mod=expansion/beta;expansion/beta/expansion' Now launch the 1.59.84216 Linux server as usual, ie with./arma2oaserver start You now have a working Linux 1.59.84216 server. Tested and verified.

Terox, could it be that your DGN1000 router has the same problem that several others have had with the same model? See this thread The suggested solution there was to return it and get a different router.

see here Start with the standard installation of BE described in the wiki so you get acquainted with how it works. If you want to have the BattlEye working directory elsewhere than the default one, edit the Arma II start script and add -bepath to the OTHERPARAMS variable. For example: OTHERPARAMS='-cpucount=2 -bepath=/path/to/my/battleye' Then copy (note copy, not "move", see 23262) battleye.so and beserver.cfg do that custom BE directory.

I'm getting the following error: File warfxpe\ParticleEffects\SCRIPTS\destruction\AirDestructionStage2.sqf, line 97 Error in expression <etDropInterval _dr; sleep (0 - (_speed / 0)); _i = _i + 1; }; deleteVehicle _sm> Error position: </ 0)); _i = _i + 1; }; deleteVehicle _sm> Error Zero divisor That's a very odd expression: sleep (0 - (_speed / 0)); Dividing by zero If the divisor wasn't zero, you'd end up with a negative value. You can't wait negative time :D

Yes, there has been similar exploits performed using other game servers. Reference: for example Possible solution: Make use of the new "v3" challenge-response variant of the GameSpy query protocol?

Funny thing ... did you know that a M1030 motorcycle is more threatening to aircraft than a T-72 tank? M1030 : threat[] = {0.5,0.5,0.5}; T72: threat[] = {0.9,0.8,0.2}; (Of course, the bike could be driven by a very angry player with a Stinger) :D EDIT: ticketed, see 22873 EDIT 2: apparently, threat values are not absolute. See Suma's comment in that ticket.

Say hello to ticket #18778: Linux dedicated servers yellow in MP server list Please add more info to that ticket if you have any. I suggest a well-written description of how to reproduce the error, even if the reproduction steps seem trivial to you. By all means, include a descriptive screenshot showing the problem. Also, do this *four* months ago, when the ticket was created. Then, vote it up.

VisceralSyns variant does work: OTHERPARAMS=-mod=@cba\;@acre\;@ace\;@acex\;@acex_ru\;@acex_usnavy\;@acex_sm Here's a variant that also works (note the single qoute characters which alleviate the need to escape the semicolons) OTHERPARAMS='-mod=@cba;@acre;@ace;@acex;@acex_ru;@acex_usnavy;@acex_sm' ...and a variant with more than one extra launch parameter: OTHERPARAMS='-cpucount=2 -mod=@cba;@acre;@ace;@acex;@acex_ru;@acex_usnavy;@acex_sm' I have verified that all three variants work. NOTE: You don't need to load @jayarma2lib on a dedicated server - see the instructions for ACRE. If you still can't make it work, there's a chance that the arma2oaserver script has been "infected" with DOS-style line endings (CRLF), which usually results in very strange behaviours. dos2unix arma2oaserver (In some distributions, that tool is called "fromdos")

Your issue is not with BattlEye. Update your game to v 1.59. See post #7 above.

Yes. Don't start the server by using "./server". Instead, edit the arma2oaserver script as instructed in step 7 of the readme.txt and then launch the server via ./arma2oaserver start

1.59 is referring to the version of ArmA II:OA, not BattlEye. The version of BattlEye is not displayed in the game browser. (The BattlEye client is version 1.146 right now, see http://www.battleye.com/index.html ) Update your game to 1.59.

c) That server appears to be misconfigured. It is a A2:Combined Operations server that loads the "@CBA_OA" mod folder, which should only be used with A2:Operation Arrowhead installations. (If the server owners sees this - check your .RPT file for an error message and remove the @CBA_OA from the -mod=... list)

Since you say you first installed A2:OA and only later installed A2, I suspect you have two separate installations, one with ArmA 2 and one with ArmA 2: Operation Arrowhead. This is why you're getting the errors you're seeing. Suggestion: make a backup of all the mods you already have installed. Then uninstall both OA and A2 and make sure they are completely gone from your harddrive. Then, reinstall the two games. First install ArmA 2. By default will end up in a folder named "Arma 2". Run ArmA 2 once. Then, install Operation Arrowhead into the *same* folder as ArmA 2. It should *not* end up in, say, a folder named "ArmA 2 Operation Arrowhead". Finally, patch the whole thing up, first using the 1.59 OA patch and then the ArmA 2 1.10 patch which came out a bit after 1.59. Tada - now you have a proper ArmA 2: Combined Operations installation. Then, you can install @CBA and @I44CO again and launch I44 via a shortcut similar to "C:\Program Files\Bohemia Interactive\ArmA 2\arma2oa.exe" -nosplash -mod=@CBA;@I44CO

Yeah, that readme really needs an overhaul... Disregard the parts that tell you to run the server using "./server" (steps 4, 5 and 6) and instead skip to step 7. Edit the arma2oaserver script to fit your setup and then launch the server using ./arma2oaserver start Next, you can follow the log output from the text file "log.2302.txt": tail -f log.2302.txt

Here's a tip: the Linux server will need the Addons, Common, Expansion and Dta folders from a Windows installation of ArmA II:Combined Ops. In particular, one does not need and should not upload any of the DLC mod folders. (BAF, PMC).

Yes. The instructions in that thread tell you to copy the game files to your Linux server. (it's step #2).

That looks like a file system error on your hard drive. (Google on the "Data error..." message and you'll find more info, then run a disk check ("chkdsk") on your computer.