killswitch

No ideas left. I'm not able to reproduce the problem using the latest beta (102209), even if I load the beta mod folders from a non-standard location like you do. Why do you do that anyways? Why load Expansion\beta from the E: drive instead of the Steam Arma II OA installation folder?(I don't have a Steam ArmA II installation so I cannot exactly replicate your setup)

@CBA_CO only works with betas newer than 100697 and with the beta game content in Expansion/beta loaded by way of -beta=Expansion\beta;Expansion\beta\Expansion

Your log output suggests that Bug 23261 is exactly what's occuring. Try using two leading forward slashes at the beginning of your absolute paths, eg -cfg=//home/arma/config/ctf/test.cfg You only load the beta game content (.pbo addons) from the beta folder in Linux. The Linux "beta exe" is the ALS itself (1.62.101906). Yes, I have used the beta mod in Linux and yes it does work. Hope that helps. Good luck! :-)

1: In general, for ArmA II 1.xx, use whatever is the latest "ALS" v 1.xx.yyyyyy. Thus, today, for the current Arma II v1.62 patch, you should use "ALS" 1.62.101906 2, 3, 4: This is most likely due to this very old bug: Linux server strips the first slash on some command line options, at least -cfg/-config The suggested workaround for that is to have two leading forwards slashes in absolute paths, eg CONFIG=//path/to/my/config.cfg 5: As you have noticed, the mpmissions folder must be in the root of the ALS installation folder. Different server instances must live in their own folders. Maybe you can just symlink the addons, common, dta, keys and expansion folders and just have a unique mpmissions folder per instance. (I have not tried this, so I do not know if that'll work. It's worth a try.) 6: Yes, AFAIK the netlog goes where it goes and you cannot change that. 6': The Windows .RPT file correspond to the log output that the ALS created (eg log.2302.txt) Crash dumps end up in core.<PID> files (unless core dumps are disabled for the user runnng the ALS). 7: That's an unfortunate chicken-and-egg problem. You have uploaded the game data files from a Windows installation, which has the "Expansion" folder with a capital first letter. Then you need to convert all file names to lowercase, which is done by first extracting the ALS archive and then you compile the "tolower" utility. The catch is that the ALS tar.gz archive contains "expansion/battleye/beserver.so". This means that at the point you're about to run "./tolower" there will be one folder named "Expansion" and another called "expansion". D-oh! :-) The solution: before you run the "install" script, move beserver.so into Expansion/BattlEye/ and remove the lower-case "expansion" folder: $ mv expansion/battleye/beserver.so Expansion/BattlEye/ $ rm -rf expansion $ ./install 8: This could be due to the other two servers suffering from the "leading slash bug" mentioned in 2 - two of the servers never start up properly. 9: Nice - that's a good way of reminding the admin to stop the ArmA II server before launching a new one. 10: Copy the Expansion/beta folder from your Windows machine into expansion/ on your Linux machine. Run ./tolower again for good measure. Then alter the OTHERPARAMS line in the arma2oaserver start script to something like this: OTHERPARAMS="-cpucount=2 -beta=expansion/beta;expansion/beta/expansion"

First post updated with links to the fixed CBA_CO, called "1.0.1 pre2".

It's difficult to tell what the problem is. Do you have an example of a server (name and/or IP address) where your version of CBA used to work, but no longer does? Also, precisely what CBA version is it that you are using? (is it the one from the first post of this thread or, for example, the CBA that's currently available via the Six-Updater and/or PlayWithSix tools? The "Six" ones are "running releases" and are more often updated than the official releases in this thread)

Check to see if there are "old" ArmA processes running from a previous run attempt. Sometimes, the start/stop script fails in stopping the arma server. Then, as you try to start a new one, it fails. After doing "./arma stop", wait a sec or so and then use "ps aux" to get a list of running processes. If there still is an older arma process running along with the watchdog bash process, kill them both. They would look something similar to this: # ps aux ... ... 12345 pts/0 S /bin/bash ./arma watchdog 12347 pts/0 Rl /arma-def/server -server -config=/arma-def/server.cfg <other launch parameters follow here>... Use the kill command to get rid of any and all old, lingering ArmA-related processes. In the example above, the two process ID:s would be stopped by # kill 12345 12347 Then, once there are no ArmA-related things running, try launching your ArmA server again.

RazorFlint, the "Server check" screenshot looks a bit off... what actual values do you have for the ARMA_DIR value in the configuration section of the server start script (arma2oaserver originally, yours is renamed to "run")? Based on the screenshot showing the directory you're running the "run" script from, it should read ARMA_DIR=/arma/server Oh, BTW - don't run the game server using the root account. Create a normal user to do that instead. Why? It's good practice because there could be bugs in the ArmA server script or binaries that could cause damage to the file system if running as root. A process running as a normal user can't do that.

Save the cash for now. You should not upload the DLC folders to your server. Remove the whole PMC folder (and any other official DLC installations such as BAF you may have uploaded) and try again.

No, I suspect it's something else. Have a look at what you saw when you tried to run the script: The error message cannot find a ruby interpreter called "ruby^M". Note the odd "^M" there. That's the ASCII 13 character - the "line feed" character. It comes from the DOS-style way of having text lines end in ASCII 10 (Carriage Return) followed by ASCII 13 (Line Feed). Unix text files should only have CR as line endings. Here's how you fix it: use the "fromdos" command to convert the script to Unix-style line endings: fromdos /home/armaserver2/.gem/ruby/1.8/gems/six-rsync-0.8.0/bin/six-rsync Now, if you don't have the "fromdos" utility installed, it may be called "dos2unix". The fromdos (and todos) tools are in the package called "tofrodos" and the dos2unix/unix2dos tools usually may come in a package named "dos2unix". Hope that helps!

Yes. You should *not* upload the PMC folder to the server.

V. 2 .bisign files are backwards-compatible with v1 signature checking. Download the BIS signing tools from DSUtils_2 and use the DSCheckSignatures.exe tool to verify that the troublesome addons have correct signature files. For your setup, that means running something like this in a command window (cmd.exe, "DOS prompt") C:\path\to\DSCheckSignatures.exe E:\ArmA\@FOG\addons\ E:\ArmA\Keys The addon signatures (*.bisign files) should be where the addons are. The Keys folder on the server should have *.bikey files.

Ask the addon authors for the correct v.2 .bisign and .bikey files for those addons. Unfortunately, it is not uncommon that addon makers fail to get their addons signed correctly... The .bikey files should be in "the arma 2 root folder Key's section", not in 'the modifications "Keys" folder'.

Or vote to get this fixed: Support waypoint in multiplayer An olden goldie...

Yes...well, one could experiment with symlinks to minimize the amount of data that needs to be copied. Your goal is four server copies with different Keys folders.

No, not four game installations. You just make several copies of the one installation.

I'm not sure what the problem is. You are running four Arma servers. Therefore, if they are all hosted on the same machine (computer), you would have four separate copies of the Arma game installation and thus four different Keys folders. You then have something like in your second picture. The first server has the key files needed for the zombies. The second server, in another folder, has a set of ACE-related keys in its Keys folder and so on. In other words: something like below. You have made four copies of the Arma game files in C:\games and named them accordingly. In each of them, there are the usual game data folders such as Addons, Common, Dta, Expansion and of course a copy of arma2oaserver.exe in each folder. Furthermore, each of them has a Keys folder you can customize: C:\games\Zombie_Server\Keys <-- Zombie-related .bikey files goes here C:\games\ACE_server\Keys <-- ACE keys C:\games\I44_Server\Keys <--- I44 keys C:\games\Vanilla_Server\Keys <-- The two stock BIS .bikey files only

You say "Windows". What specific variant and version of Windows does the server have? Microsoft has released two updates that improve performance a little bit with AMD Bulldozer architecture processors such as your 3280. These updates are for Windows 7 and Server 2008 R2: KB 2645594 KB 2646060 Note that "Windows Server 2008" is not the same as "Windows Server 2008 R2" If those hotfixes apply to your server, install them and see if they help. Another tip: check the power saving settings in the server's Control Panel->Power Options. Make sure it's set to either "Balanced" or perhaps even "High Performance".

There are new text strings in the betas that aren't there in the stock 1.60 game data files. Upload the expansion\beta\expansion folder from your Windows installation to the Linux server and then add the following to the OTHERPARAMS line in the Linux server startup script ("arma2oaserver"): -beta=expansion/beta;expansion/beta/expansion As an example, the OTHERPARAMS line would look something like this afterwards: OTHERPARAMS='-cpucount=2 -beta=expansion/beta;expansion/beta/expansion' That will fix the "unknown string" errors.

Most likely, there's already a server running on that port. Sometimes, "arma2server stop" doesn't actually stop a running Arma server. When the Arma server is running you'll find two processes related to it: The server itself ( For example a process named /home/armaserver/server/arma2co/a2oaserver ) The watchdog script ( Process name has something like "./arma2server watchdog" in it) If these two are not gone after you have run "./arma2server stop", kill them manually.

See leading dot in the path? You probably have a typing error in the start script on the ARMA_DIR line. I'm guessing it looks like this: ARMA_DIR=./home/games/arma2 Remove the dot at the beginning of the path: ARMA_DIR=/home/games/arma2 Why should you not run the Arma servers as root? There are severaly reasons why, and they apply to server software in general: Because they don't need to. It's potentially unsafe to do so: You could make a mistake when you are working with the servers logged in as root. You might accidentally delete important system files elsewhere. There could be a bug in the software that could damage the rest of the server if the software was run as the superuser. It's simply good practice to run a server with the minimum level of privileges it needs to do the job.

That won't work. The first server instance uses ports 2302,2303 and 2305. The lowest available port above 2302 for your second server instance would be port 2306. Try that.(See here: What ports does Arma use? ) Furthermore, to echo what the others have said - make sure your firewall rules are correct.

Actually, the Linux Arma 2 launch script, "arma2server" does not have OTHERPARAMS like arma2oaserver has, so that's why "it doesn't work". Solution: extract the arma2oaserver script from one of the Linux Arma 2 OA server archives and use that to launch the Arma 2 server or modify the stock arma2server script so that it makes use of OTHERPARAMS.

Yes. A 2.4 GHz Bulldozer CPU core is probably far too weak for Arma. However, check to see if you have CPU frequency scaling enabled in both the BIOS and the OS and make sure the CPU is able to scale all the way up to 3.5 or even 3.7 GHz when loaded. Alternatively, experiment with turning CPU frequency scaling off in the OS and let the CPU run at full speed and see if that helps.

You are using a modified start script (arma2oaserver) with an extra line in the configuration section. The original script that comes with the server archive does not have the "MOD=..." line. How does the rest of your non-standard arma2oaserver script look like? Also, you do not need to to explicitly load the expansion mod folder, which that extra "MOD=..." line suggests. Revert to the original start script from the the a2oa-server-1.60.87589.tar.bz2 archive and make that work. Also, since we're now at a post-1.60, pre-1.61 stage you'll need to upload the Expansion\beta folder from a Windows machine and use the OTHERPARAMS line like this: OTHERPARAMS='-cpucount=2 -beta=expansion/beta;expansion/beta/expansion' (If you don't load the beta game data you may see errors related to missing strings in the server log)