Yep, we've run into this same problem with our Linux dedicated server.

*raises hand*

We hit this wall too.

Thirded, fourthed, or whatever. This is a real kicker for linux servers, and it is only going to get worse over time, even with things like Apex.

Our own content we can consolidate to reduce the number of files, but other community content we have to choose between removing it to stay under this limit or editing others content without their permission to repackage it into fewer pbos. Neither of which are particularly pleasant solutions.

We would genuinely appreciate this being looked into.

This is a major issue for community member using linux servers!

Can confirm, we are having this same issue

arma3server on Linux seems to choke at around 1511 open files. you can verify this by looking at the /proc/[pid of server]/fd folder and seeing all the open file descriptors. It never goes beyond that number.

Can confirm, we are having this same issue.
.# ll /proc/20075/fd | wc -l
1051 <----- max. open files !!!!!!!!

.# ulimit -Hn -Sn = 65536

similar issue T84836

confirm: This is a major issue for community member using linux servers!

So, this is being really optimistic right now but.....

It's maybe fixed with the current perf build? (As of posting, arma3server_performance_162_138470_v20_linux)

Just gave it a run on my server, loaded the filler mod and our usual modset, loading ~1850 PBOs. Seemed to work fine!

It's not fixed.
~# ll /proc/15446/fd | wc -l
1053 <--- server can not find

1051 <--- work fine

This issue still remains as of version 1.64 and completely cripples arma3server with a good-size mod collection on Linux.

any comment from bistudio would be good

As far as I can tell, Arma currently does not put a limit to a number of file handles that can be open. It all comes down to your system's settings.

In order to influence the number of files you can have open simultaneously, you can use either:

1. temporary solution (will be gone after you log out or restart):

ulimit -n # will return your current limit
ulimit -n 4096 # or any higher number. Just make sure that it's greater then what "ulimit -n" returned originally

2. permanent solution:

as a root add the following to your /etc/security/limits.conf and restart your system just to be sure
arma3server - nofile 4096 # the same rules I described for ulimit above apply here

Given some of you complain that updating the limit via "ulimit- n" does not help, maybe there's some other limit set on your system. E. g. file locks (ulimit -x).

Thanks for the reply. In my case I am ubuntu server (V12.04 iirc) Firstly in my case ulimit -n returns (10240) and ulimit -x returns (unlimited). Also in /etc/security/limits.conf the (10240) is set for both the soft and hard limits. Via:

• soft nofile 10240
• hard nofile 10240

I'd recommend attempting to reproduce as per the steps in the original ticket. There's a really tiny mod (274kb) that you can experience this with. To clarify further on 'When you attempt to join the server you will be unable to.' - The server will show in the server browser but you can not connect to it you will stuck in a loading screen that may eventually timeout.

Just saw this today:
1.66.140166 new PROFILING branch with PERFORMANCE binaries, v13, server and client, windows/linux
+ fix for issues on Linux server with too many PBO (unable to connect to afterward)

https://forums.bistudio.com/topic/160288-arma-3-stable-server-166-performance-binary-feedback/?page=78#comment-3145555

After testing 1.66 v14 binaries for the past week, I feel pretty confident saying this bug has been fixed, and the issue can probably be closed (as I can only speak for myself).

Confirmed Fixed - Ran the filler mod alongside our standard modpack so ~2000 pbos
Good job!