Finding out the values of kernel options related to sysctl.conf and sysctl.d

Question

On my Ubuntu machine, in /etc/sysctl.conf file, I've got reverse path filtering options commented out by default like this:

#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

but in /etc/sysctl.d/10-network-security.conf they are (again, by default) not commented out:

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

So is reverse path filtering enabled or not? Which of the configuration locations takes priority? How do I check the current values of these and other kernel options?

Solution 1

Checking the value of a sysctl variable is as easy as

sysctl <variable name>

and, by the way, setting a sysctl variable is as straightforward as

sudo sysctl -w <variable name>=<value>

but changes made this way will probably hold only till the next reboot.

As to which of the config locations, /etc/sysctl.conf or /etc/sysctl.d/, takes precedence, here is what /etc/sysctl.d/README file says:

End-users can use 60-*.conf and above, or use /etc/sysctl.conf directly, which overrides anything in this directory.

After editing the config in any of the two locations, the changes can be applied with

sudo sysctl -p

Solution 2

This kind of stuff is usually in the /proc and/or /sys kernel interfaces (first, keep in mind nothing in those directories is a regular disk file, they are all direct lines to the kernel).

So, eg:

»for x in /proc/sys/net/ipv4/conf/*/rp_filter; do echo -ne "$x "`cat $x`"\n"; done
/proc/sys/net/ipv4/conf/all/rp_filter 0
/proc/sys/net/ipv4/conf/default/rp_filter 1
/proc/sys/net/ipv4/conf/em1/rp_filter 1
/proc/sys/net/ipv4/conf/lo/rp_filter 0
/proc/sys/net/ipv4/conf/wlan0/rp_filter 1

Looks like I have rp_filter set for em1, wlan0, and "default". You can set or unset them by just writing to the file handle:

»cd /proc/sys/net/ipv4/conf/lo
»echo 1 > rp_filter
»cat rp_filter
1
»echo 0 > rp_filter
»cat rp_filter
0

As mentioned, this is direct communication with the kernel, so that takes effect immediately. These are not configuration files. If you try and do something wrong:

»echo whatever > rp_filter
bash: echo: write error: Invalid argument

Which is not to say you can't screw things up this way, of course. And be sure to read the comments below.

Solution 3

To complete the accepted answer, while it's true that /etc/sysctl.conf settings take precedence over the ones in /etc/sysctl.d/, the example exposed in the original question shows two commented out variables in /etc/sysctl.conf:

#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

and the same variables not commented out in /etc/sysctl.d/10-network-security.conf:

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.all.rp_filter=1

This may be misleading because a comment is not a setting, but only a remark of what could be a setting.

In this situation, the variables are actually both set to 1, despite the fact that in the stronger config file they're commented out.

If in /etc/sysctl.conf we had:

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

then the variables would eventually be set to 0.

Comments

[goldilocks]

Definitely using config files is much better. I was not suggesting you write a script, just illustrating that those are not "read only" values and can be used to make manual tweaks. ;)

[derobert]

That shell script is a rather interesting way to re-write sysctl -a ...

[Nils]

Is this not sysctl -e for edit and sysctl -f for executing the config?

[Desmond Hume]

@Nils linux.die.net/man/8/sysctl

[goldilocks]

True, but (depending on the nature of your file browser) perusing proc/sys might be considered more convenient, which is one reason it is worth knowing about. Another is that WRT to getting information programmatically, that interface is more efficient than piped "system(sysctl)" type stuff, and works regardless of language, available libs, etc.

[Nils]

Right - strangely both options work.

[Nils]

Not quite. There are already some cases where a write with echo may fail, while using sysctl -w works. You might also encounter systems, where /proc is not mounted.

[goldilocks]

You misunderstand what I mean by programmatically, perhaps I need to clarify: I did not mean shell scripts. There is a native C equivalent of sysctl (see man 2 sysctl), however, this is not ported to most other languages (it is in some), and in these cases the best option is to read or write to proc. It may well be that bash's echo may fail, as I can say that the high level stream I/O functions available in C and other languages can. The low level read/write will not, however. In any case, knowing about the proc interface is important, which is why I brought it up...

[goldilocks]

Also note from the sysctl man page: "The parameters available are those listed under /proc/sys/. Procfs is required for sysctl support in Linux." This implies to me that sysctl won't work either if proc is not mounted (I have not checked directly). And, again, it is better to be aware of the interface and how it works than not. I think the bases are decently covered by the two separate answers to this question.

[goldilocks]

As a (hopefully final) quick comment, I have run across people who are dubious of using the proc interface programmatically because low level I/O on what is apparently the filesystem will be a (hardware) bottleneck. This is part of the reason I emphasized that they are not really disk files, ie., their is no slow hardware interface involved to cause such a bottleneck.