How to Change Kernel Runtime Parameters in a Persistent and Non-Persistent Way?

Kernel runtime parameters are settings that control the behavior of the Linux kernel on your system. These parameters can affect a wide range of system functions, such as memory allocation, network performance, and CPU scheduling.

Understanding how to change these parameters is crucial for optimizing system performance and troubleshooting issues that may arise. There are two main ways to change kernel runtime parameters: non-persistent changes and persistent changes.

Non-persistent changes modify the kernel's behavior temporarily, lasting only until you reboot your system. Persistent changes, on the other hand, modify the kernel's behavior permanently and persist across reboots.

Changing Kernel Runtime Parameters in a Non-Persistent Way

Non-persistent changes to kernel runtime parameters are changes that are temporary, meaning they do not survive a system reboot. These changes can be made using command-line tools such as sysctl or echo. Once the system is rebooted, the changes made to the kernel runtime parameters will be lost, and the system will revert to its default settings.

One major advantage of non-persistent changes is that they allow for quick testing of different configurations without making any permanent changes to the system. This flexibility comes with a downside, as it requires constant attention from the administrator to ensure that any desired non-persistent changes have been re-applied after each reboot or service restart.

Step-by-Step Guide for Non-Persistent Changes

The following steps detail how to change kernel runtime parameters in a non-persistent way using command-line tools

• Identify which kernel parameter(s) you want to modify.

• View current values for all sysctl variables or for an individual parameter:

sysctl -a

or

cat /proc/sys/[parameter_name]

• Change the parameter value using either method:

echo [value] > /proc/sys/[parameter_name]

or

sysctl -w [parameter_name]=[value]
sysctl -p

• Verify that your new value(s) took effect by checking the parameter again:

cat /proc/sys/[parameter_name]

Examples of Non-Persistent Changes

Below are some examples of kernel runtime parameters that can be changed in a non-persistent way:

• net.ipv4.tcp_syncookies set to 0 to disable SYN cookies, which are used to protect against certain types of denial-of-service attacks.

• vm.swappiness controls the degree to which the kernel prefers to swap out inactive processes over reclaiming file-backed pages in memory.

• net.ipv4.ip_forward set to 1 to enable IP forwarding on a node acting as a router.

• kernel.sem adjusts the maximum values for System V IPC semaphores, message queues, and shared memory segments.

• fs.file-max sets the maximum number of file handles available system-wide.

Changing Kernel Runtime Parameters in a Persistent Way

Making persistent changes to kernel runtime parameters means that the changes will remain even after the system reboots. These changes are saved in configuration files so they can be loaded automatically when the system initializes. This is different from non-persistent changes which only temporarily modify kernel settings and revert back to their original values upon system restart.

Persistent changes are helpful for making long-term modifications to kernel settings that need to remain consistent across multiple reboots. Additionally, persistent changes can be made through configuration files, which can be useful for automating configurations on multiple systems.

Step-by-Step Guide for Persistent Changes

To make persistent changes using configuration files, you will need to modify the appropriate configuration file for the parameter you want to change. Typically, these configuration files are located in the /etc/sysctl.d/ directory. Here's a step-by-step guide:

• Open a terminal window and switch to root user:

sudo su

• Navigate to the /etc/sysctl.d/ directory:

cd /etc/sysctl.d/

• Create a new file with .conf extension in this directory:

nano custom-settings.conf

• Add your desired kernel runtime parameters with their corresponding values into this file (one parameter-value pair per line):

net.ipv4.tcp_fin_timeout=30
vm.swappiness=10

• Save and close the file by pressing CTRL+X followed by Y and then ENTER.

• Refresh sysctl settings using command:

sysctl --system

Examples of Persistent Changes

Many kernel runtime parameters can be changed in a persistent way through configuration files. Here are some common examples:

• net.ipv4.tcp_fin_timeout This parameter controls the time that a connection stays in the TIME_WAIT state after it's closed. The default value is usually 60 seconds, but this can be reduced for faster connection closing.

• vm.swappiness This parameter controls how aggressively the kernel swaps memory pages between RAM and swap space. Lower values (like 10) result in less swapping and more use of physical memory.

• fs.file-max This parameter sets the maximum number of open files that can exist on the system at any given time. Increasing this value can be helpful for systems with high file I/O demands.

Comparison

Best Practices

Test Changes First: Prior to implementing any changes, it is important to test those changes in a non-production environment. This allows for any issues or conflicts to be identified prior to rolling out the changes on production systems.

When to Use Each Method: Choosing whether to make non-persistent or persistent kernel runtime parameter changes depends largely on the intended scope of the change and its potential impact. Non-persistent changes are ideal for temporary modifications that do not need to be maintained between system reboots, while persistent changes are better suited for long-term modifications that should persist across reboots.

Documentation: Always document the changes you make, including the reason for the change and the expected impact. This helps with troubleshooting and future maintenance.

Conclusion

Changing kernel runtime parameters can be a powerful tool for optimizing system performance and functionality. Non-persistent changes allow for quick testing and temporary fixes, while persistent changes ensure settings remain after reboots. Understanding both methods enables administrators to choose the appropriate approach based on their specific needs and requirements.