redshirt_ensign

Yeah, your server is failing to start. Something is wrong with your files, folders or configs. We can sort it out from here via PM.

OK, well you do have some rules but the default policy is ACCEPT so yeah iptables are fine. You are on a single public IP too so thats fine too. Must be the (arma) server itself. You do have a an RPT with the linux server but it piped to STDOUT and then the startup script redirects it to a log file. By default it is named after the port you are using - eg: "log.2302.txt" - but in your script you are naming it "serverlog.txt". Do you have that log file?

Sorry mate I was away from home for a few days there. You may not have setup iptables but it would be better to see an output from "iptables -L -vn" to check if there are any pre-configured rules in place that you are not aware of. You did not answer my question about the IP address(es) of the server. Is it a private or public IP? Are there multiple IPs? (output of "ifconfig" would show this) Are you sure the server is starting properly? Can we see some of the RPT log (serverlog.txt)?

Define "all the ports are open" ... Where is the server? A dedicated? VPS? Home network? Is it on a private IP (10.* 192.* etc) and behind a NAT device? If so have you forwarded _all_ the required ports? Any reason why you are using 2305 and not the default of 2302? When you say "remote" you are talking about putting the IP directing into "Remote" search of in-game multiplayer browser? (which should work regardless of Gamespy working) On linux what is you IPTABLES setup? (run "iptables -L -vn")

Check the RPT file (on linux is just console output piped to a log, probably called "log.2302.txt" unless you have changed defaults) for what PBOs it is not finding when you connect. Post snippets here if you want me to check it over. Post your "arma2oaserver" script. You have edited it to set paths right? Problem could be path to beta, I always had to include param for it on my linux server (using the OTHERPARAMS var). This was mine: OTHERPARAMS="-beta=expansion/beta;expansion/beta/expansion -profiles=wasteland -name=wasteland -cfg=./wasteland/basic.cfg -cpucount=2 -maxMem=2047" NOTE: you will need to remove the -profiles -name and -cfg params or change them to suit you current "player" profile dir name.

All that stuff is just ENV vars that are being set into the shell that the script is running in. Some of them then get used as command line parameters in the actual bit of the script that runs the server binary: ${SERVER} >>${LOGFILE} 2>&1 -server -config=${CONFIG} -port=${PORT} -pid=${PIDFILE} As you can see, only SERVER (the binary), LOGFILE, CONFIG, PORT and PIDFILE are being used. Just setting ENV vars isn't enough for the server to know about them, you need to actually submit them as params to the "server" binary. Where did you get that start script anyway? Both the current 1.63 Linux and even the previous 1.62 Linux bundle uses a start script that has an ENV called OTHERPARAMS (which is included in the command line call to server) and by default it includes the "-cpucount=2" param already: #======================================================================= #======== CONFIGURATION PARAMETERS ======== #======== MUST BE EDITED MANUALLY TO FIT YOUR SYSTEM PARAMETERS ======== #======================================================================= ARMA_DIR= CONFIG= PORT=2302 PIDFILE=${ARMA_DIR}/${PORT}.pid RUNFILE=${ARMA_DIR}/${PORT}.run LOGFILE=${ARMA_DIR}/log.${PORT}.txt SERVER=${ARMA_DIR}/server OTHERPARAMS=-cpucount=2 #======================================================================= and ${SERVER} >>${LOGFILE} 2>&1 -server -config=${CONFIG} -port=${PORT} -pid=${PIDFILE} [b]${OTHERPARAMS}[/b] Although for yours (based on the params you seem to want) I would make that OTHERPARAMS="-cpucount=2 -maxMem=2047 -nologs" Lastly, as Savage already pointed out, you will only ever get the 2nd core to be used for AI threads, so don't be alarmed if you first start the server and still only see 1 core getting constantly thrashed at 100%, the 2nd core will start fluctuating up to more and more usage as the need for AI processing occurs. This is why the optimal server for Arma 2 is to have a very high clocked dual core (or quad since that leaves some cores to run mysql and/or the rest of the OS) running on dedicated hardware with no hyperthreading or any other potential drain on pure uninterrupted access to that 1 single core that is doing almost all the work. Hope this helps :)

Wow thanks for posting that. Very curious little bundle. He seems to have kludged the DB i/o layer that would normally use Arma.NET SQL calls for hive interaction, and replaced it with a system of output (DB writes/queries) via console log (using debug messaging I assume) and inputs (DB reads) by building temp sqf scripts and running them. I once contemplated doing something similar for basic db support in Wasteland ... but this very complex by comparison. He has even got an "epoch" binary running it all (I assume it is just a wrapper to the linux dedi binary). My only concern is whether there is any hive lag due to all that console log scanning and sqf file creation/loading. Still very clever none the less. I recently went the other way and just started running the win dedi via WINE instead (talking to local linux mysql server but using the DLL for sql support).

How do you plan to run the hive db (DayZ) stuff anyay when Linux Dedi has no CallExtension (DLL) support?

FWIW I have just managed to get an MSO 4.5 server up and running on Ubuntu 12.04 64bit (Win dedi running via WINE) with PDB running off native (linux) mysql server. Mostly I just followed HOWTOs for doing the winetricks installs required for DayZ server (dotnet4, dx9, etc) and then copied into place a fully working Arma2 OA / MSO folder from a Windows server. Could not get the dotnet mysql connector to install via WINE but didn't have to since we had already placed the DLL in the server root on the windows server when we had PDB issues there. MySQL was pretty simple since you just need basic linux mysql-server install then create the user and grant it all privs. One thing that held me up for a few days was that all of the WINE stuff (especially the winetricks and creating the wineprefix to run it all under) needs to be done in 32bit mode (WINEARCH=win32). Otherwise you won't get dotnet4 to install and a bunch of other things fail too. If your server is remote (headless) then you will first need to go through what I did to get a VNC-based Xorg windows session that runs from the main server console (using a dummy display module and pre-baked xf86config). Most VNC and/or xRDP services will create new X sessions on connection (and then kill them on disconnect), and this will be no good for running a dedi server. I know this isn't a very good write-up (sorry) but I am trying to recall it off the top of my head and it took me about 2 weeks, 10 installs of Ubuntu, 3 different Window Managers, 4 different xRDP/VNC installs and unknown WINE setups to get it right myself :P Let me know your setup and I can start to try and tailor the advice accordingly.

Should be plenty. I had the number #2 ranked Arma (Wasteland) server in Australia for 2-3 months there - so it was full 60/60 for large chunks of the day and never empty - and even that on ran up about 350-400GB outbound (maybe another 150-200GB inbound).

Forget about 70. Even decent dedicated servers struggle to do that without desync (especially Wasteland). You might do 50 but only if the cpu quality of your vps is good enough. You preferably need 2 cores with decent clock speed and pray that the xen host your vps is on isn't over worked.

What? They are finally putting callExtension support in the linux binary? When/where was that announced??? EDIT: Oh, did I miss the sarcasm in that? lol, trolled me good :p

You can't. None of us can. That's the problem. The main server / script engine will run one core at 100% the whole time and AFAIK only some of the AI processing will be threaded off onto a 2nd core which will then fluctuate in % util. Cores 3 and 4 will do nothing (or you can run a 2nd server off them). Arma 2 is all about pure single core performance. So if you have the option to disable hyperthreading on that E3 go for it.

Yep, that script is completely default. You will be running on 2302 (but we already pretty much knew that). You have to understand, Arma2 doesn't have RCON natively. It is BattlEye that provides an RCON interface to the server. So (with the exception of manually defining a new -bepath param) there is nothing in the startup script that will affect you getting RCON access. You need to concentrate on BattlEye. With the linux install (assuming you have done it all correctly), your linux BattlEye lib "beserver.so" should be at [ARMA2DIR]/expansion/battleye/beserver.so and you should make the cfg file at [ARMA2DIR]/expansion/battleye/beserver.cfg along with [ARMA2DIR]/expansion/battleye/bans.txt [ARMA2DIR]/expansion/battleye/scripts.txt [ARMA2DIR]/expansion/battleye/remoteexec.txt etc etc and Yes, every single file (including mission PBOs) should be in lowercase for linux. Like I said, you will know if you have got the cfg file successfully found if it gets renamed to "beserver_active_abc1234.cfg" after you start the server (where abc1234 is some random value). If the cfg file doesn't get renamed, don't even bother trying to connect an RCON client as it won't be listening for it.

"arma2server" is the start script. run command "less arma2server" to view contents (press Q to exit when done). If you haven't edited it, it is doubtful that your port is non standard. Are you sure you are putting the beserver.cfg in the right directory? EDIT: What did you "port check" with anyway? You know it is UDP port 2302 right? If people are playing arma on port 2302 then that is the port BE will be using (but it won't run at all if it doesn't find the cfg file where it expects it to be). You will know if your beserver.cfg file has actually been found by BE if the filename gets changed to beserver-RANDOM.cfg ("RANDOM" will just be some random chars)