Configure sysctl Temporarily and Persistently and Verify the Applied Values

Overview

Linux kernel parameters can be changed at runtime with sysctl. Temporary changes take effect immediately, but to retain them after a reboot, you need to save them in configuration files under /etc/sysctl.d/.

This article targets RHEL 8-compatible Linux systems and uses vm.swappiness as an example to verify the following workflow.

Check the current effective value
Temporarily change it to 20 with sysctl
Persistently set it to 30 under /etc/sysctl.d/ and apply it without rebooting
Set it to 40 in a configuration file that is loaded later and verify precedence when settings conflict
Confirm that the final value of 40 remains in effect after a reboot

The values 20, 30, and 40 used here are examples for verifying that the settings are applied. Because vm.swappiness affects memory reclaim behavior and the tendency to use swap, choose an appropriate value for your workload in production environments.

Step 1: Check the Current Effective Value

First, check the value before making any changes. The output of sysctl shows the effective value currently being used by the kernel.

sudo sysctl vm.swappiness

The value at this point varies by environment. In the following steps, compare the requested value with this effective value at each stage.

Step 2: Temporarily Change the Value

Change vm.swappiness to 20 with sysctl -w, then immediately read the effective value again.

sudo sysctl -w vm.swappiness=20
sudo sysctl vm.swappiness

If the effective value is 20, the temporary change has been applied. This change alone does not persist the value after a reboot.

Step 3: Create a Persistent Setting in sysctl.d

To apply the setting after a reboot, create a configuration file under /etc/sysctl.d/. Here, set the first persistent value to 30.

sudo tee /etc/sysctl.d/60-example-swappiness.conf > /dev/null <<'EOF'
vm.swappiness = 30
EOF

The configuration filename uses a numeric prefix so that the load order is easy to identify.

Step 4: Apply the Persistent Setting Without Rebooting

Load only the file you created with sysctl -p, then check the effective value.

sudo sysctl -p /etc/sysctl.d/60-example-swappiness.conf
sudo sysctl vm.swappiness

If the effective value is 30, the requested value written in the file has been applied to the kernel.

Step 5: Add a Conflicting Configuration File

Define the same vm.swappiness parameter in another file and set its value to 40. Because 90- comes after 60- in lexicographic order, this lets you verify precedence when the same parameter appears in multiple files.

sudo tee /etc/sysctl.d/90-example-swappiness.conf > /dev/null <<'EOF'
vm.swappiness = 40
EOF

Step 6: Check the Conflicting Settings

Confirm that the two configuration files specify different values for the same parameter.

sudo grep -H 'vm.swappiness' /etc/sysctl.d/60-example-swappiness.conf /etc/sysctl.d/90-example-swappiness.conf

At this point, the file numbered 60 requests a value of 30, while the file numbered 90 requests a value of 40.

Step 7: Reload All sysctl.d Settings and Verify the Precedence Result

Reload the systemd-sysctl configuration in the same way it is processed during system startup, then check the effective value.

sudo systemctl restart systemd-sysctl
sudo sysctl vm.swappiness

If the effective value is 40, the setting in the later 90-example-swappiness.conf file is ultimately active.

Splitting the same parameter across multiple configuration files can easily cause unintended overrides. Except when deliberately testing conflicts, clearly define which file should be managed as the authoritative configuration.

Step 8: Reboot the System

Reboot the system to verify that the persistent setting is also applied during startup.

sudo systemctl reboot

After the reboot, reconnect to the server as usual.

Step 9: Check the Effective Value After the Reboot

After reconnecting, check vm.swappiness.

sudo sysctl vm.swappiness

If the effective value is 40, the sysctl.d configuration has also been applied after the reboot, and the value that took precedence during the conflict has been retained.

If the Setting Is Not Applied as Expected

Treat temporary changes and persistent settings separately. If sysctl -w produces the expected value but the value changes only after a reboot, check the location of the persistent configuration files and any possible conflicts. If loading an individual file with sysctl -p produces the expected value but a different value becomes active after reloading with systemd-sysctl, check whether a later-priority configuration file is overriding the same parameter.

Kernel parameters directly affect system behavior. Do not apply test values unchanged in a production environment without first confirming their meaning and permitted range.