fix: WRN The open files limit is too low (1024) and may cause crash

[Mikeburke14]

The game can sometimes crashes with the following message, this PR applies this fix.

`2024-11-14T23:12:48 0.020 WRN The open files limit is too low (1024) and may cause crashes. Recommended is at least 10240. Follow these steps to increment it:
- Open /etc/security/limits.conf with a text editor: 'sudo editor /etc/security/limits.conf'
- Add or update the line: 'sdtdserver soft nofile 10240'
- Save the file and exit the editor
- Apply the changes: Log out and back in or restart the system`

[vinanrra]

Hi @Mikeburke14 did you try to do this at your host machine?

Because I saw this issue GameServerManagers/LinuxGSM#4612, and it was resolved, setting the ulimit at host machine, because even if we increase the ulimit at the container it will be constrained by the host machine, I'm not sure if we also need to set this at the container.

[Mikeburke14]

Hi @vinanrra,

The problem is that the sdtdserver doesn't get the ulimit settings, our server got hit by this message a number of times

2024-11-14T23:12:48 0.020 WRN The open files limit is too low (1024) and may cause crashes. Recommended is at least 10240. Follow these steps to increment it:
- Open /etc/security/limits.conf with a text editor: 'sudo editor /etc/security/limits.conf'
- Add or update the line: 'sdtdserver soft nofile 10240'
- Save the file and exit the editor
- Apply the changes: Log out and back in or restart the system

This is the ulimit we saw for the container before appling the fix

(the value 1024000 was a test to double check it was appling it to the container)

root@aabbb158e02e:~# ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 62537
max locked memory           (kbytes, -l) 64
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024000
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) unlimited
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

And this is the ulimit for the user, with open files (-n) 1024

sdtdserver@aabbb158e02e:~$ ulimit -a
real-time non-blocking time  (microseconds, -R) unlimited
core file size              (blocks, -c) unlimited
data seg size               (kbytes, -d) unlimited
scheduling priority                 (-e) 0
file size                   (blocks, -f) unlimited
pending signals                     (-i) 62537
max locked memory           (kbytes, -l) 64
max memory size             (kbytes, -m) unlimited
open files                          (-n) 1024
pipe size                (512 bytes, -p) 8
POSIX message queues         (bytes, -q) 819200
real-time priority                  (-r) 0
stack size                  (kbytes, -s) 8192
cpu time                   (seconds, -t) unlimited
max user processes                  (-u) unlimited
virtual memory              (kbytes, -v) unlimited
file locks                          (-x) unlimited

On the host OS we had the ulimit set and could see the changes only seemed to apply to the root user of the container not the sdtdserver user (ulimits had been set for both userId 1000 and sdtdserver.

[vinanrra]

@Mikeburke14

Thanks for the PR, I will merge, as you wrote, it's recommended to have this increased