Increase the process limit of a Linux game server

A Linux game server can show errors such as Too many open files, refuse to start a process, or interrupt a service once the process limit is reached. That limit protects the system, but a value that is too low can get in the way of a FiveM, Minecraft, or Rust server, or an application managed by Pterodactyl, on a VPS, a virtual machine, or a dedicated server.

This guide explains how to measure the current limit, pick a sensible setting, and apply it at the right level. The goal is not to set an unlimited value everywhere, but to increase only the capacity you actually need and verify the result after a restart. The commands assume SSH administration with an authorized account, sometimes root or one with sudo.

Distinguish processes from open files

Two Linux limits are often confused. The process limit concerns the number of processes a user can create. The open files limit concerns the descriptors used by sockets, logs, configuration files, and backups. A game server can hit either one.

Start by identifying the user that runs the service. With an administrator session, then check your shell's limits:

whoami
ulimit -u
ulimit -n
ps -u utilisateur-du-serveur --no-headers | wc -l

Replace utilisateur-du-serveur with the account that is actually used. The ulimit -u command shows the process limit and ulimit -n the open files limit. The counter provided by ps lets you compare current usage against the limit without modifying the VPS.

RAM, disk space, SSD storage, processors, CPU, and bandwidth are other resources to watch. They are not increased by changing nproc. An outage too quickly blamed on the process limit may actually come from RAM saturation or a full disk.

Check the service and its manager

Your terminal's value is not necessarily the game server's. A service started by systemd, a Docker container, or a control panel such as Pterodactyl can receive its own limits. First check the main process:

ps -eo user,pid,ppid,cmd | grep -E 'java|FXServer|RustDedicated' | grep -v grep

For a systemd service, replace mon-serveur.service with its name:

systemctl status mon-serveur.service
systemctl show mon-serveur.service -p LimitNPROC -p TasksMax -p LimitNOFILE

LimitNPROC and TasksMax are not interchangeable. The former concerns the service's process limit, while the latter controls the number of tasks allowed for the systemd group. A value can therefore look correct in the shell while the service remains capped.

Also check the service's logs:

journalctl -u mon-serveur.service -b --no-pager

Look for messages related to fork, resource temporarily unavailable, Too many open files, and permissions. The logs provide the context you need before touching the configuration.

Choose a sensible value

First measure the real need during a period of load. Note the account's process count, the errors in the logs, and any spikes related to scripts, workers, extensions, or backup tasks. Adding headroom avoids outages during a spike, but an oversized value reduces the point of the protection.

On a shared machine, do not change the global limit just for one server. Prefer a targeted setting on its account or its systemd unit. On a Linux VPS dedicated to a single purpose, the setting can be more flexible, while still keeping an eye on memory, CPU, and the number of tasks. The virtualization of the virtual server does not remove the limits of the guest system or those of the service manager.

A hosting provider may give root access, a control panel, or partial managed support. Identify what your team administers before modifying the kernel, systemd, or the container. To host a game, favor a documented, reversible configuration over a global setting applied to every virtual server.

In a cloud offering or a virtual dedicated hosting plan, the process limit remains a limit of the Linux operating system and of the launched service. It is not a direct indicator of the number of processors available or of high availability. To manage several servers, centralize monitoring, backups, and alerts instead of raising every ceiling indiscriminately.

If the error is about open files rather than processes, work on LimitNOFILE or ulimit -n. Raising only the process count will not fix that other cause. If the server no longer responds on its IP address, also check the service, the firewall, and the network before changing nproc.

Adjust a systemd unit

For a server started by systemd, create a local override rather than editing the file provided by the package directly:

sudo systemctl edit mon-serveur.service

Add only the necessary directives in the service section:

[Service]
LimitNPROC=4096
TasksMax=4096
LimitNOFILE=65535

The numbers above are a sample configuration to adapt after measuring. Save, then reload systemd and restart the service:

sudo systemctl daemon-reload
sudo systemctl restart mon-serveur.service
systemctl show mon-serveur.service -p LimitNPROC -p TasksMax -p LimitNOFILE

Then check the logs and the service's state. A successful restart is not enough: verify that the process actually uses the new value and that the game server accepts connections on its port. Test from a client machine, not only from the VPS.

Set a limit for a user

For a service started by a dedicated account, PAM limits can work when the program is launched in a compatible session. Edit the limits file carefully and add a targeted rule:

serveurJeu soft nproc 4096
serveurJeu hard nproc 4096

The soft and hard limits apply to sessions that load this mechanism. They do not automatically replace the restrictions of a systemd unit, a container, or the administration panel. After the change, open a new SSH session to test with ulimit -u.

Do not set the hard limit to unlimited without an operational reason. A bounded limit makes diagnosis easier and reduces the risk that a faulty script creates a large number of processes. Keep a copy of the configuration and plan a documented rollback.

The Pterodactyl and Docker cases

If the server is managed by Pterodactyl, the process may be isolated in a container. The effective limit then depends on the container's startup and the settings applied by the node. Check the server and node configuration before modifying the host system. The panel may also apply an independent memory or CPU limit.

For Docker, check the limit actually visible inside the container:

docker exec -it nom-du-conteneur sh -lc 'ulimit -u; ulimit -n; cat /proc/1/limits'

A fix applied only on the host may not be propagated to the container. After any change, recreate or restart the container according to your operating method, then read /proc/1/limits again. Also check the volumes, logs, and disk space used by the server.

Validate after the change

Run a four-step check: confirm the effective value, start the server, watch the logs during a ramp-up of load, and check resource usage. Keep a copy of the setting and document the date, the service involved, the IP address or node concerned, and the reason for the change.

If the error persists, look for the exact cause in the logs. It may be a process leak, a script loop, a lack of memory, a full disk, or an open files limit. A higher limit sometimes masks the symptom without fixing the problem.

For durable operations, automate an alert on the number of tasks and monitor the VPS metrics. Also test backup restoration and the restart procedure. A limit setting is only useful if it fits into a complete server administration.

To go further, also read our Docker on a VPS guide, the advice on securing a dedicated server, the method for diagnosing FiveM performance, the guide to testing a Pterodactyl restore, and the information about Ubuntu VPS plans.