Increasing the open file limit on a Linux game server

A Linux game server can show Too many open files while the disk, RAM and CPU still appear to have room. This error means the process has hit a file descriptor limit. Descriptors are used notably for files, network sockets and logs opened by the server.

This guide explains how to measure the limit actually applied, increase it for a systemd service and verify the result without changing the whole machine needlessly. The method suits a game server administered on a Linux VPS, an Ubuntu or Debian virtual machine, or on a dedicated server.

Recognizing the Too many open files error

The most common symptoms are refused connections, configuration files that cannot be opened, errors in the logs, or a service that works after a restart and then fails again under load. The message can come from the game, a proxy, a container or a monitoring component.

Do not change the limit blindly. Start by identifying the process involved and checking its effective limit. The value in your SSH session is not necessarily that of the service started by systemd, Docker or a control panel.

The file limit is different from the disk space, bandwidth and memory available on the VPS. A virtual server can still have RAM and SSD available while refusing a new network socket because its process has reached nofile.

Checking the session and process limits

In a shell session, run:

ulimit -n
ulimit -Hn

The first command shows the soft limit, used by default by programs started in this session. The second shows the hard limit, which bounds the soft limit. For an already running service, find its PID then check the limits file:

systemctl status nom-du-service
pidof nom-du-binaire
cat /proc/PID/limits | grep -i "open files"

Replace PID with the number returned by pidof. The Max open files line shows two values, the soft limit then the hard limit. This is the information that confirms the setting applied to the process is the expected one.

Counting the open descriptors

A high limit does not fix a descriptor leak. Compare the current usage with the limit:

ls /proc/PID/fd | wc -l
cat /proc/PID/limits | grep -i "open files"

For a more detailed view, lsof -p PID lists the open files and sockets if the tool is installed. Watch for continuous growth, thousands of identical logs or connections that are never released. In that case, first look for the cause in the game server, a plugin, a proxy or a script before increasing the limit permanently.

On a VPS, also check the neighboring resources: CPU usage, RAM, storage space, inodes and firewall state. General saturation can produce other errors in parallel, but it does not change the service's LimitNOFILE value.

Relating the limit to the server's resources

The file limit is set at the operating system level, but the hosting environment still matters. On a VPS, virtualization shares a physical server between several virtual machines. Check the CPU capacity, RAM, SSD disk space, bandwidth and the presence of an IP address suited to your use. A dedicated server provides reserved physical resources, while a VPS favors flexible provisioning.

A cloud VPS plan may offer a resizable virtual machine, but changing the plan does not automatically change the service's limit. When comparing several configurations, check the data center location, the advertised redundancy, backups and monitoring tools instead of looking only at the number of vCPUs.

Root access, an admin panel or a deployment tool can change how the server starts. Note the distribution, the service manager, the firewall rules and the backup procedure before modifying nofile. This information keeps you from fixing the wrong instance or losing the setting when the virtual server is rebuilt.

Increasing a systemd service's limit

For a server started by systemd, create a local override with:

sudo systemctl edit nom-du-service

In the editor, add only:

[Service]
LimitNOFILE=65535

Save, then reload the configuration and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart nom-du-service
sudo systemctl status nom-du-service

The number 65535 is an example of a technical ceiling, not a universal recommendation. Choose a value consistent with the software, the expected load and the overall system limit. After the restart, check the value actually received:

PID=$(systemctl show -p MainPID --value nom-du-service)
sudo cat /proc/$PID/limits | grep -i "open files"

Case of a server in Docker

If the game runs in a container, a change made only in your host shell is not enough. Check the process limit inside the container and set the limit at launch, for example:

docker run --ulimit nofile=65535:65535 image-du-serveur

With Compose, the setting depends on the version and the engine used. After recreating the container, check the limit from the environment that actually runs the server. Remember to keep this setting in your deployment file so that a new creation does not lose it.

Verifying after the change

A complete check has four steps:

• confirm the service is active with systemctl is-active nom-du-service;
• re-read /proc/PID/limits for the right process;
• check the latest errors with journalctl -u nom-du-service -n 100 --no-pager;
• watch the descriptor count during a representative load period.

A monitoring dashboard can track CPU, RAM, SSD storage, network connections and open descriptors. It helps distinguish a process limit from a lack of virtual server resources or a network configuration problem.

If the error comes back, compare the counter's progression with the connections, temporary files and logs. A higher limit should buy time for diagnosis; it does not replace a software fix or log rotation.

Avoiding common mistakes

• Do not change ulimit only in your SSH session if the server starts as a service.
• Do not confuse the soft limit with the hard limit.
• Do not restart only the game without checking the process actually used by the manager.
• Do not copy an extreme value without measuring the consumption and capacity of the machine.
• Do not hide a descriptor leak by raising the limit at every incident.

Document the exact service name, its startup method, its Ubuntu or Debian system and the applied setting. This documentation is especially useful when migrating to another VPS or host.

Before any major operation, plan a configuration backup and an emergency access. To complete your preparation, also see our guide on initial hardening of a dedicated server and the one on dedicated server backups.