DNice

You need to be root or run sudo to use this it seems?

I have the headless client successfully connected and working... at least until BattlEye kicks it. Without a working beclient.so from BattlEye (which let's get real will never happen, they can't find the time to reply to an e-mail), trying to run a headless client on a BattlEye enabled server will just have you running into a brick wall: "vehicleManagerHC - 331 cached entities out of 359" > You were kicked off the game. (BattlEye: Client not responding) There's a very simple solution to this that I hope Bohemia implements... just making the HeadlessClient bypass BattlEye, at least for Linux, since BattlEye won't do anything about this within the next decade.

Finally got it working, by downloading and installing all these unneeded dependencies. Although, there was one specific one that was giving me trouble, since it does not exist any longer on newer distros, note this is for 32-bit distros, 64-bit distros will be slightly different but the idea behind it is the same: Step 1, ldd steamclient.so and find all the missing dependencies Step 2, apt-get install libx11-6 libusb-1.0-0 libopenal-dev libglib2.0-0 libdbus-glib-1-2 libnm-glib-dev add any additional dependencies you may be missing Optional Step 3, ln -s /lib/i386-linux-gnu/libudev.so.1 /lib/i386-linux-gnu/libudev.so.0 This is for newer distros, this was causing my server to crash, since it's a dependency dropped by newer distros. This line is for 32-bit distros, locate libudev.so.1 on your x64 and the link it the same way. Hope this helps, albeit it's a bit more complicated.

However, can people actually connect to your server now??? Anyways, the included steamclient.so seems to be all screwed up, ALL these dependencies are really not needed... linux-gate.so.1 => (0xb774e000) libtier0_s.so => not found libvstdlib_s.so => not found librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb6618000) libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xb64e4000) libusb-1.0.so.0 => /lib/i386-linux-gnu/libusb-1.0.so.0 (0xb64cd000) libopenal.so.1 => /usr/lib/i386-linux-gnu/libopenal.so.1 (0xb6478000) libpulse.so.0 => /usr/lib/i386-linux-gnu/libpulse.so.0 (0xb6429000) libgobject-2.0.so.0 => /usr/lib/i386-linux-gnu/libgobject-2.0.so.0 (0xb63d6000) libglib-2.0.so.0 => /lib/i386-linux-gnu/libglib-2.0.so.0 (0xb62ca000) libdbus-glib-1.so.2 => /usr/lib/i386-linux-gnu/libdbus-glib-1.so.2 (0xb62a4000) libnm-glib.so.4 => not found libnm-util.so.2 => not found libudev.so.0 => not found libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb625d000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6258000) libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb616f000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6153000) /lib/ld-linux.so.2 (0xb774f000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb5fa3000) libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xb5f81000) libudev.so.1 => /lib/i386-linux-gnu/libudev.so.1 (0xb5f6e000) libjson-c.so.2 => /lib/i386-linux-gnu/libjson-c.so.2 (0xb5f63000) libpulsecommon-4.0.so => /usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-4.0.so (0xb5ef4000) libdbus-1.so.3 => /lib/i386-linux-gnu/libdbus-1.so.3 (0xb5ea8000) libffi.so.6 => /usr/lib/i386-linux-gnu/libffi.so.6 (0xb5ea1000) libpcre.so.3 => /lib/i386-linux-gnu/libpcre.so.3 (0xb5e63000) libgio-2.0.so.0 => /usr/lib/i386-linux-gnu/libgio-2.0.so.0 (0xb5ce2000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb5cc5000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xb5cc0000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xb5cb9000) libcgmanager.so.0 => /lib/i386-linux-gnu/libcgmanager.so.0 (0xb5c9b000) libnih.so.1 => /lib/i386-linux-gnu/libnih.so.1 (0xb5c82000) libnih-dbus.so.1 => /lib/i386-linux-gnu/libnih-dbus.so.1 (0xb5c78000) libwrap.so.0 => /lib/i386-linux-gnu/libwrap.so.0 (0xb5c6d000) libsndfile.so.1 => /usr/lib/i386-linux-gnu/libsndfile.so.1 (0xb5bfb000) libasyncns.so.0 => /usr/lib/i386-linux-gnu/libasyncns.so.0 (0xb5bf4000) libgmodule-2.0.so.0 => /usr/lib/i386-linux-gnu/libgmodule-2.0.so.0 (0xb5bef000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xb5bd5000) libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xb5bb1000) libresolv.so.2 => /lib/i386-linux-gnu/libresolv.so.2 (0xb5b99000) libnsl.so.1 => /lib/i386-linux-gnu/libnsl.so.1 (0xb5b80000) libFLAC.so.8 => /usr/lib/i386-linux-gnu/libFLAC.so.8 (0xb5b4c000) libvorbisenc.so.2 => /usr/lib/i386-linux-gnu/libvorbisenc.so.2 (0xb59d4000) libvorbis.so.0 => /usr/lib/i386-linux-gnu/libvorbis.so.0 (0xb59a7000) libogg.so.0 => /usr/lib/i386-linux-gnu/libogg.so.0 (0xb599e000)

Replacing the steamclient.so did fix the crashing and the pthread_cancel error coming up, however, even though the server is up, no one can connect, it just kicks anyone off the game with a "You were kicked off the game."

This new update has seemingly made mods crash the server. Mission runs without mods, but when mods are added: 17:00:48 "WASTELAND SERVER - Server Compile Finished" 17:00:48 "[extDB] Startup..." libgcc_s.so.1 must be installed for pthread_cancel to work ./start.sh: line 15: 22513 Aborted (core dumped) ./arma3server -bepath="$battleye" -cfg="/$networkConfig" -config="$serverConfig" -name="$profileName" -mod="$mods" -exThreads=1 -enableHT -bandwidthAlg=2 -loadMissionToMemory -autoInit -noTexHeaders -maxMem=2047 -world=stratis -port=2312 -noSound All dependencies are there and linked correctly, including libgcc_s.so.1. These exact parameters worked fine on 1.36. When shutting down the server, same error (pthread_cancel) at the end pops up even when not running mods, but it doesn't crash through midway loading, like it does with mods. Any way to revert back to 1.36?

Try running the game with the following parameters: -malloc=tbb4malloc_bi -exThreads=7 -cpuCount=4 -high -maxVRAM=2047 -maxMem=2047 -world=empty -skipIntro -nosplash -noPause The malloc option will have the greatest effect on performance. Try a custom memory allocator like winhoard for example. Download the winhoard.dll, and put it in your dll folder in Arma 2 OA, and set -malloc=winhoard. You can try a bunch as I said. Another thing you wanna make sure you do is by going to your Arma2OA.cfg file, in your Documents folder, and setting GPU_MaxFramesAhead=1; GPU_DetectedFramesAhead=1;

Another option is to run under WINE. Oddly enough, I've actually noticed a significant performance improvement running 1.63 under WINE compared to running the Linux server files on 1.62. Better server FPS, better client FPS in areas where it would usually drop compared to rest of map, and noticeably more efficient CPU usage. The Linux version would just hog 1 processor before, and offload a bit of work to another one, now the workload is divided much better between processors with WINE. Only issue I still have of course is the lack of support for callExtension.

'The War' would basically be any mod referencing to the former Yugoslavia war.

It almost seems as if they sabotaged Arma 2 so we hopefully move to Arma 3. I already own Arma 3, but prefer to play OA, but with errors such as these: Error Undefined variable in expression: _dofilter File ca\ui\scripts\handleGear.sqf, line 521 in their own core files...

What they seemingly changed is their interpreter breaks script execution as soon as there is any undefined variable, the interpreter previously seemed to just ignore these variables, and continue executing code. If there's any chance for an undefined variable to pop up, you now have to manually check if it is undefined in your scripts, which sucks coming all of a sudden.

Thank you for the swift reply. May I ask if there is any approximate timeframe in place for when Linux steam integration will be completed? While I'm at it, I might as well try my luck and ask if there's any plans to introduce the callExtension function for Linux servers.

Are linux servers using this build supposed to show on steamworks??? Because mine isn't listing, even after including steamports into my server.cfg file.

Just to add a final update and closure to this thread. Top level staff from [RISE] (Valgarr and Sirhc) who advised me they were not aware of the situation came to my server and respectfully discussed with me what changes they wanted from the mission to remove [RISE] content from it they felt was their intellectual property, and we agreed on terms so we could move forward from this past issue and hopefully work together in the future. I wish to thank them for being mature and helping resolve this issue. In regards to Battleye, they once more show their incompetency by not having the decency to even reply to one of my e-mails to them(other than the automated excuse for a reply, which says a reply can take a few days). 10 Days passed, not one reply.

An update on the issue, for people who in the future might get attacked by other server staff. I had figured out the issue already a while ago, they were using a malicious squad.xml file to connect. Why Bohemia Interactive would not provide an internal function to reject or disable squad urls, is beyond me... Considering how fast the server would crash after connect, it was either a tiny picture file that was malicious, or more likely they were using some sort of code in the XML to dry up the memory and cause the server to crash. Just about every server I've been to on Arma 2 is susceptible to this attack... attacks possible range from bandwidth raping to desyncing clients to DoS as I saw against my server. Bohemia really needs to fix this... Someone could bandwidth rape with a TB file... I unfortunately tested this on my own server even, banned my own GUID, IP, you name it, and was STILL able to bandwidth rape, as Battleye doesn't initialize until the download is complete... Sadly, RISE have already secured their server from squad.xml files. Anyways, for other server owners, you are going to want to disable all internet access on the user running the server, except for the essential game ports, like server port, client ports, battleeye port. I can't guide you how to do this on Windows, as my server runs on Linux. Also, I catfished the idiot that was running the XML DoS attack on my server, I didn't institute the fix on my server until he crashed the server a few times with the same IP, Name, so I could get his GUID when he failed. Here is his GUID, other server owners and probably Battleye, may wanna ban this guy... GUID: 20fdbb23b4709a17562e33271ef669a4. Log Proof (omitted lines in between to protect users on my server, other than the attacker) :