Inspect and Safely Tune Linux's /proc/sys/net Settings

A backlog error in your logs points at a kernel ceiling, so /proc/sys/net/ is where you check it. The installed proc_sys_net(5) page is short: it covers the directory, net.core.bpf_jit_enable, and net.core.somaxconn, and it is not a complete catalogue of every networking knob on a modern kernel.

Allow about fifteen minutes. You need a shell, the procps-ng sysctl command, and a Linux host where you can read the relevant pseudo-files. Reading is normally unprivileged; writing a kernel setting needs root or the capability and policy your host grants for that operation. The examples below are tested against Linux 6.8.0-139-generic, man-pages 6.7, and procps-ng 4.0.4, but values and available files are host-specific.

1. Confirm the local tools and kernel

Start with read-only version checks. This stops a copied example from silently describing a different host:

$ uname -sr
Linux 6.8.0-139-generic
$ sysctl --version
sysctl from procps-ng 4.0.4
$ man -P cat 5 proc_sys_net | sed -n '1,90p'

2. List the networking namespace without changing it

The manpage says /proc/sys/net/ contains networking material, while the kernel and loaded modules decide which descendants exist. Ask sysctl to list readable variables:

$ sysctl --all --pattern '^net\.' | sed -n '1,40p'
net.core.bpf_jit_enable = 1
net.core.somaxconn = 4096
# more net.* variables may appear here

Your output will be longer and can differ between kernels, network namespaces and loaded features. The command reads values only, and the pattern is anchored at net., so it avoids mixing unrelated kernel., fs. or vm. settings into the review.

For an exact path check, use the pseudo-files directly:

$ ls -l /proc/sys/net/core/somaxconn /proc/sys/net/core/bpf_jit_enable
-rw-r--r-- 1 root root 0 ... /proc/sys/net/core/bpf_jit_enable
-rw-r--r-- 1 root root 0 ... /proc/sys/net/core/somaxconn

These files report a size of zero because they are procfs interfaces, not ordinary files. Do not edit them with a text editor; use sysctl or a deliberate write to the pseudo-file once you have established the setting's meaning and rollback value.

3. Understand the two settings documented locally

• net.core.somaxconn is a ceiling for the backlog argument passed to listen(2). It is not the application's requested backlog, a count of current connections, or a guarantee a service can accept that many clients: the application, protocol, available memory and other queue limits still matter.
• net.core.bpf_jit_enable is documented by reference to bpf(2). It controls the kernel's BPF just-in-time compiler, not whether every BPF program is permitted, and not whether a particular tracing or networking tool will work. Treat changes to it as security-sensitive kernel policy.

Read both, and use the value without the name when a script needs a number; keep the purpose in a comment so a future reader does not mistake it for a live queue depth:

$ sysctl net.core.somaxconn
net.core.somaxconn = 4096
$ sysctl -n net.core.somaxconn
4096

Record the current BPF JIT value before touching anything:

$ sysctl net.core.bpf_jit_enable
net.core.bpf_jit_enable = 1

4. Test a reversible somaxconn change

Changing a sysctl affects kernel behaviour immediately and can affect a running service. Take a maintenance window for a production test, capture the old value, and make sure you have a root shell or an approved sudo rule. This example changes only the current runtime value:

$ old_somaxconn=$(sysctl -n net.core.somaxconn)
$ printf 'old somaxconn: %s\n' "$old_somaxconn"
old somaxconn: 4096
$ sudo sysctl -w net.core.somaxconn=512
net.core.somaxconn = 512
$ sysctl -n net.core.somaxconn
512

Use a value suited to your actual service, not 512 by habit: this is a test of the ceiling, not a recommendation. An application that asks listen(2) for a backlog above 512 will now be capped at 512, and existing connections are not rewritten.

Undo the runtime change as soon as the test is complete. The shell variable exists only in the shell where you captured it:

$ sudo sysctl -w "net.core.somaxconn=$old_somaxconn"
net.core.somaxconn = 4096
$ sysctl -n net.core.somaxconn
4096

5. Keep persistence separate from a runtime test

sysctl -w changes the current kernel state; it does not by itself create a persistent configuration file. Persistence is distribution-specific and commonly applied during boot or service startup. Before adding a file under /etc/sysctl.d/, confirm which configuration manager owns it and whether another file already sets the same key:

$ rg -n '^(net\.core\.(somaxconn|bpf_jit_enable))\s*=' /etc/sysctl.conf /etc/sysctl.d 2>/dev/null
$ sysctl --system --dry-run 2>/dev/null | rg 'net\.core\.(somaxconn|bpf_jit_enable)'

The second command is a preview where the installed sysctl supports it, and it does not write a value. If your version lacks the option, read its --help output and use the distribution's documented dry-run or configuration inspection method.

Do not persist the temporary value simply because the command worked. A persistent change needs an owner, a reason, a rollback path and a reboot or startup verification plan. If you add a managed drop-in, remove that exact drop-in to undo it, then reload through the same mechanism and verify the result; do not delete an entire sysctl directory.

Common traps

• Reading too much into an unknown key. It can mean the kernel does not expose that feature, the command is in a different network namespace, or the spelling is wrong. It is not proof a reboot will create the key.
• Trusting a successful write. A successful somaxconn write does not prove a service is healthy: check the service's own configuration, socket state and application metrics separately.
• Trusting a successful read. A successful BPF JIT read does not grant BPF privileges or validate a program. Review the relevant kernel security policy and the tool's own diagnostics.
• Treating a dump as an API. Do not use sysctl --all output as a stable interface: it includes settings outside this manpage and can change with the kernel.
• Skipping input validation. Do not paste untrusted values into a privileged shell command; validate numeric input and quote shell variables when a value comes from automation.