BSD Links · New Links · Advocacy · Drivers · Events · Flavours · FAQs · Guides · Programming · Security · Software · User Groups

This is the BSDA Study Guide Book written via a wiki collaboration. This is a work in progress. You may contribute to or discuss this specific page at http://bsdwiki.reedmedia.net/wiki/Modify_a_kernel_parameter_on_the_fly.html. Modify a kernel parameter on the fly Concept BSD systems maintain kernel MIB variables which allow a system administrator to both view and modify the kernel state of a running system. Be able to view and modify these MIBs both at run-time and permanently over a system boot. Recognize how to modify a read-only MIB. Introduction Consider this excerpt from the sysctl(8) man page on FreeBSD: The sysctl utility retrieves kernel state and allows processes with appropriate privilege to set kernel state. The state to be retrieved or set is described using a "Management Information Base" (MIB) style name, described as a dotted set of components. As you can see sysctl is a powerful technology to tune your system. Some sysctl variables can be modified on-the-fly and thus change how your system works without rebooting. Other values, when changed, only take effect after a reboot. When this is the case, it makes (more) sense to update your sysctl.conf/loader.conf and reboot your system. TODO: mention that there are a lot and the total amount varies Some common sysctl variables include: TODO: add brief description of each: hw.machine_arch kern.clockrate kern.maxfiles kern.maxproc kern.ostype kern.securelevel TODO: point to other wiki page for details kern.version net.inet.ip.forwarding TODO: point to other wiki page for details vm.loadavg Examples List all sysctl variables: # sysctl -a Show subset of sysctl variables relevant to cpu: # sysctl -a | grep cpu Show subset of sysctl variables for a top-level identifier or for a sub-level identifier: # sysctl kern Or: # sysctl net.inet List only the specific variable that you need: # sysctl kern.ostype kern.ostype: FreeBSD TODO: maxusers is not portable, please replace this example with maxproc or maxfiles # sysctl kern.maxusers kern.maxusers: 93 TODO: maybe mention opaque values and -o Update a sysctl variable: TODO: blackhole is not portable, maybe replace with something that is portable and applicable to beginning admin # sysctl net.inet.tcp.blackhole net.inet.tcp.blackhole: 0 # sysctl net.inet.tcp.blackhole=2 net.inet.tcp.blackhole: 0 -> 2 # sysctl net.inet.tcp.blackhole net.inet.tcp.blackhole: 2 Now you can test tcp blackhole with some tools like nmap. When you understand that variables you want do change in your system, you must update sysctl.conf file. In new system sysctl.conf is empty(only comment line). You can update sysctl.conf with editor like vi an save it. # cat sysctl.conf net.tcp.blackhole=2 Some variables, such as hardware variables that are read-only on the running system, cannot be set in sysctl.conf. In that case and you need add lines in loader.conf which is read earlier in the boot process. The information presented here is also applicable to OpenBSD, although the kernel MIB variables do differ. Hence the blackhole example will not work on OpenBSD. In addition OpenBSD does not use a loader.conf file for adjusting kernel MIB variables. TODO: explain how to know which values can be modified on the fly, and which require a reboot. TODO: show on NetBSD for proc.PID or proc.$$ Practice Exercises For OpenBSD and FreeBSD. Change on the fly these variables: kern.maxproc to 1000 net.inet.ip.forwarding to 1 (What does this do?) Set these variables in system files (as described above) and reboot, check that variables are changed after rebooting. TODO: let's just use same variables that are common to all these for a beginning admin -- by keeping few differences between the BSDs will make this book easier for new admin Set these variables such that the changes will remain following subsequent reboots. More information sysctl(8), sysctl.conf(5), loader.conf(5)