Read and Safely Change Linux Kernel Settings in /proc/sys

You will finish with a small, repeatable workflow for inspecting kernel variables under /proc/sys, translating between file paths and sysctl names, and making a runtime change that you can undo. The local reference is proc_sys(5) from Linux man-pages 6.7, and the installed command here is procps-ng 4.0.4 on Linux 6.8.

Allow about fifteen minutes. You need a shell and a mounted proc filesystem. Reading normally needs no elevated privileges. Writing usually needs root, and a change can affect networking, memory management, logging or other running services. The examples use vm.swappiness, but the right value depends on the workload and the host's policy.

1. Confirm the filesystem and tools

Start with read-only checks. These commands do not change kernel state:

$ findmnt -no FSTYPE,TARGET /proc
proc /proc
$ command -v sysctl
/usr/sbin/sysctl
$ sysctl --version
sysctl from procps-ng 4.0.4

If findmnt does not show /proc, stop here. A missing proc mount is a system setup problem, not a reason to create a directory and write pretend settings into it. If sysctl is absent, you can still use the files directly, but install or enable the normal procps tooling through your system's ordinary package process before standardising scripts around it.

Checkpoint: you should know whether you are reading the live /proc filesystem and which sysctl implementation will run.

2. Read a value directly

Each file below /proc/sys represents a kernel variable. Read one with an ordinary command:

$ cat /proc/sys/vm/swappiness
10
$ cat /proc/sys/kernel/hostname
server.dixon.cx

The output is the current value, not a copy from a configuration file. It can change while you are working, and some values are host-specific. Do not build a script around the hostname shown above.

The proc_sys(5) interface accepts string values, integer values and long integer values. A string may end with a newline or a NUL character. Integers and longs may be written in decimal or hexadecimal notation, such as 0x3FFF. When a setting accepts several integer or long values, separate them with a space, tab or newline. Other separators produce EINVAL.

3. Find settings without guessing paths

List the top-level names and inspect a particular directory with ordinary, read-only commands:

$ find /proc/sys -maxdepth 1 -type d -printf '%f\n' | sort
abi
debug
dev
fs
kernel
net
user
vm
$ find /proc/sys/vm -maxdepth 1 -type f -printf '%f\n' | sort | head
admin_reserve_kbytes
compact_memory
compact_unevictable_allowed
dirty_background_bytes
dirty_background_ratio

The exact list depends on the kernel and its configuration. Keep the search targeted when you know the subsystem. A broad recursive dump is noisy and can expose settings you did not mean to collect.

For sysctl, replace each slash in the file path with a dot and omit the /proc/sys/ prefix. These two commands read the same variable:

$ cat /proc/sys/vm/swappiness
10
$ sysctl vm.swappiness
vm.swappiness = 10

Use the file form when you need an exact path in a small shell script. Use the dotted form when working with tools or configuration conventions that already use sysctl names.

4. Record the old value before writing

A runtime write is not automatically persistent, and it is not automatically harmless. Before changing a setting, record the current value and read the relevant subsystem documentation. For this example, save the live swappiness value without changing it:

$ setting=/proc/sys/vm/swappiness
$ old_value=$(cat "$setting")
$ printf 'old swappiness: %s\n' "$old_value"
old swappiness: 10

Do not use this example as a recommendation to raise or lower swappiness. It only demonstrates the mechanics of a reversible write. If you are investigating a production performance issue, capture workload, memory pressure and monitoring data first.

5. Apply one temporary change

This is the first state-changing step. It requires elevated privileges and can alter how the running kernel behaves. Make sure the value is intentional, and use a maintenance window for a service-sensitive host:

$ printf '%s\n' 10 | sudo tee /proc/sys/vm/swappiness >/dev/null
$ cat /proc/sys/vm/swappiness
10

The value 10 is used here because it is the value observed before the example, so this particular run is a no-op on this host. Replace it only after deciding on a value for your own system. Do not write a value copied from an unrelated host.

If the kernel rejects the value, the write fails. Check the shell's exit status immediately:

$ printf '%s\n' 10 | sudo tee /proc/sys/vm/swappiness >/dev/null
$ printf 'write status: %s\n' "$?"
write status: 0

A failed write does not prove that the path is wrong. The value may be outside the setting's accepted range, the file may be read-only, or the kernel may reject its format. Read the error and re-check the exact variable instead of retrying blindly.

6. Undo the runtime change

The direct write changes the running kernel only. Restore the value you recorded when testing is over:

$ printf '%s\n' "$old_value" | sudo tee /proc/sys/vm/swappiness >/dev/null
$ cat /proc/sys/vm/swappiness
10

If the shell holding old_value has gone away, do not guess. Ask the service owner or change record for the intended value, then verify it with the same read command. A reboot may restore a distribution default, but it is a disruptive recovery method and should not be treated as an undo button.

7. Understand persistence and failure boundaries

Writing a proc file normally affects the current boot. A later boot may load a different value from system configuration, a distribution service, a container runtime or a kernel default. The proc_sys(5) interface describes the live pseudo-filesystem; it does not promise that a runtime write survives reboot.

Do not make a change persistent until you have identified the owner of the setting and documented a rollback. Persistent sysctl configuration is a separate operational decision. Check it after testing with your distribution's configuration tools, and keep the runtime observation separate from the file that may be applied at boot.

Some values are security-sensitive or service-disrupting. Treat network forwarding, namespace controls, ptrace restrictions, kernel logging controls and memory limits as changes requiring review. Root access only gives permission to attempt a write; it does not make the value safe.