Server linux 1.56 strange issue

[pietrotc 10]

I have this strange issue after the 1.56 update :

 

only the first A3 server installed  work correctly , the other installed after the first don't start (the server  crash ).

 

I have different account in my server, every account have a A3 server linux installed/update with steamcmd.

 

All the A3 servers have the same configuration except the game server port and the steam port .

 

All the A3 servers are installed with then same procedure, i have reinstalled two times the server with ubuntu 12.04 64 bit and with ubuntu 14.04 64 bit but i got the same problems.

 

If i stop the first server installed and try to start the other server don't work.

 

Every server have this log error :

 

username can be replaced with different account name

 

Server 1 with ubuntu 14.04 64 bit

 

11:06:44 SteamAPI initialization failed. Steam features wont's be accessible!
11:06:44 DS_
11:06:44 /home/username/.local/share/Arma 3 - Other Profiles\Player\
11:06:44 Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz
segmentation fault (core dump created)

Server 2 with ubuntu 12.04 64 bit

 

22:50:29 SteamAPI initialization failed. Steam features wont's be accessible!
22:50:29 DS_
22:50:29 /home/username /.local/share/Arma 3 - Other Profiles\server4\
22:50:29 Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
segmentation fault (core dump created)

Any suggestions?

 

 

[Pictureclass 19]

We got the same error and problems. 

 

On the working server comes after the CPU Information the Line

 

12:01:35 sessionID: 8f75d156fed326379e26ae096f96624b35a0b11b

 

Maybe its related to this?

 

Edit:

 

Error Reporting

 

If you host multiple Servers on Linux with diffrent linux users, only one server will start. all other not. (Log see above)

You have to restart the whole root Server to start another server, from another user.

 

If you host the Server with one user, multiple Servers are possbile

[Pictureclass 19]

Hotfix: Host all arma Servers with the same Linux user. Checked it. Updated my first post

[edge100x 2]

This same problem occurs on Windows right now when servers are run as services under different users. I submitted more data through feedback.arma3.com.

 

The running-everything-as-one-user workaround unfortunately isn't appropriate for a shared hoster that gives FTP access to its customers so that they can make changes directly to the server, as that allows any customer to access other customers' files.

[pietrotc 10]

This same problem occurs on Windows right now when servers are run as services under different users. I submitted more data through feedback.arma3.com.

 

 

 

Thx

[Florian69 1]

Good evening,
I'm looking for someone with this problem since yesterday to find a solution.
I run a french company of game server rental, all of my clients with arma 3 server can not use their server due to this problem since this update.
There is no other solution than to use the same user to run any servers?
Compared to our management system, each game server has a user of its own, using a single user for all servers require that we change all our panel, the developers of the game have not provided a solution?
Thank you for your answers

[iWazaru 11]

 

This same problem occurs on Windows right now when servers are run as services under different users. I submitted more data through feedback.arma3.com.

The Tracker is down due to a security breach, and redirecting to the troubleshooting category of the Bi-forum. maybe one of you should report this here with the detailed information of the issue: https://forums.bistudio.com/forum/153-arma-3-troubleshooting/

Look at feedback.arma3.com and click on the link for have "more information" ( He give this page: https://data.bistudio.com/mailing/html/arma3-dayz-feedback-tracker.html )

[Master85 1]

I think the problem is a file created at

'/dev/shm/sem.Statistics config file mutex'

when running multiple servers by different users the file gets created by the first server instance.

server instances created by different users fail to access this file ( because of file permissions) and therefore fail to start.

[Florian69 1]

I think the problem is a file created at

'/dev/shm/sem.Statistics config file mutex'

when running multiple servers by different users the file gets created by the first server instance.

server instances created by different users fail to access this file ( because of file permissions) and therefore fail to start.

 

Thank you for the information, I simply apply a chmod 777 on this file and for now I can restart servers of my customer at the same time with a different user for each and it works.

Thank you very much Master85

[edge100x 2]

Unfortunately, there does not seem to be a similar workaround available on Windows, so those of us on Windows are stuck waiting for a fix from BI.

[0z0n3 0]

Unfortunately, there does not seem to be a similar workaround available on Windows, so those of us on Windows are stuck waiting for a fix from BI.

 

Just received notification from NFO they're pulling the plug on new Arma 3 servers it appears, too bad...servers have been excellent.  Customer service is the fastest I've ever had experience with too.  Real shame.

 

Message from NFO GSP:

 

"We have been unable to find a workaround for the serious bug in ArmA3 that is preventing us from running multiple servers on the same machines -- a critical part of shared hosting. We also have not seen any evidence that BI is looking into the problem. For the time being, we consider ArmA3 to be an unsupportable game, and we have disabled it on our order page."

[Rellikplug 11]

Is NFO the only provider having issues?  There must be more providers considering pulling the plug on Arma 3 because of this.

[george_ 17]

Hello, sorry for the inconvenience, we are looking into it. You are right, the Linux issue is due to permissions to semaphore, we already have fix for it. 

 

As for the Windows servers, I have problem to reproduce the issue (locking is done differently). I tested multiple DS servers on single Windows machine by simply running multiple servers under various users at the same time but with no luck to reproduce the issue. I guess the trick is to run DS as services as you mentioned. Since the FT is still down, can you please post more details about how exactly you are running the DS? Does it simply locks or DS crashes? Do you have any Rpt files?

[pedeathtrian 99]

Thank you for the information, I simply apply a chmod 777 on this file and for now I can restart servers of my customer at the same time with a different user for each and it works.

Thank you very much Master85

Oh yes, allow any proccess in the system post and wait on this semaphore! Genius.

You could at most create a group for all users that run arma servers, and assign this group to semaphore, and make it readable and writeable by the group.

But I personally wouldn't do even that. Applications know better than you what permissions to put on system objects. Unless they don't, haha.

[pietrotc 10]

I think the problem is a file created at

'/dev/shm/sem.Statistics config file mutex'

when running multiple servers by different users the file gets created by the first server instance.

server instances created by different users fail to access this file ( because of file permissions) and therefore fail to start.

 

 

Thx i set with chmod 666 and it's work :D

[edge100x 2]

Reproducing this on Windows should be a matter of creating two servers, each under a separate user, and then running them as services (such as through Firedaemon), also under the appropriate users.  One server will start up normally and the other will hang.

 

I imagine the culprit is some similar system-wide lock, but I have not been able to determine what it is using Process Monitor or other tools.

[Rellikplug 11]

To add to edge100x's post related to Windows servers, server RPT and BIDMP links here.

 

https://forums.bistudio.com/topic/188231-nfo-156-update-disables-steam-api-initialization-on-vds-instances/#entry2985654

[george_ 17]

The fix of DS for Windows and Linux version should be in the DEV (r. 134731). Can someone please confirm it's working (I've tested it only in my lab conditions)?

[edge100x 2]

george_, I can confirm that the performance binary from today does fix the problem on Windows.

[george_ 17]

Thanks for confirmation, the fix should be also part of the new performance build.