Red Hat Bugzilla – Bug 312481
sysctl.conf settings not "sticking" at boot
Last modified: 2014-03-16 23:08:48 EDT
Description of problem: I have added this line to /etc/sysctl.conf: net.netfilter.nf_conntrack_tcp_be_liberal = 1 However, on reboot, this seems to have no effect. Eg. On a freshly rebooted system: # cat /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal 0 # /sbin/sysctl -p net.ipv4.ip_forward = 0 net.ipv4.conf.default.rp_filter = 1 net.ipv4.conf.default.accept_source_route = 0 kernel.sysrq = 0 kernel.core_uses_pid = 1 net.ipv4.tcp_syncookies = 1 net.netfilter.nf_conntrack_tcp_be_liberal = 1 # cat /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal 1 What gives? Version-Release number of selected component (if applicable): procps-3.2.7-16.fc7 initscripts-8.54.1-1 How reproducible: Everytime Steps to Reproduce: 1.Add the line above to /etc/sysctl.conf 2.Reboot machine 3.cat /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal shows 0 and not 1 Additional info: ]# grep sysctl /etc/init.d/* /etc/init.d/network: sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1 /etc/init.d/network: sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1 /etc/init.d/network: action $"Disabling IPv4 packet forwarding: " sysctl -w net.ipv4.ip_forward=0 /etc/init.d/network: action $"Disabling IPv4 automatic defragmentation: " sysctl -w net.ipv4.ip_always_defrag=0 /etc/init.d/NetworkManager: sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1 /etc/init.d/nfs: /sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT >/dev/null 2>&1 /etc/init.d/nfs: /sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT >/dev/null 2>&1 /etc/init.d/nfs: /sbin/sysctl -w fs.nfs.nlm_tcpport=0 >/dev/null 2>&1 /etc/init.d/nfs: /sbin/sysctl -w fs.nfs.nlm_udpport=0 >/dev/null 2>&1
Reassigning to initscripts. The reason is that sysctl -p -e is called only in rc.sysinit, and /etc/initi.d/network. Hence any settings for kernel modules not loaded at that point in the boot sequence are not effective. For this reason, I think sysctl -e -p should be run at the end of the boot up sequence.
Reassigned to initscripts maintainer.
This is probably best done as a modprobe.d script or udev rule for the specific module - after all, modules can be loaded/unloaded at any time.
I see your point. But, taken to it's logical conclusion, we'd scrap sysctl.conf completely. Actually, that would be the right thing to do - it's currently a badly defined ad hock kludge. I presume this issue will be shaken out during the initscripts reworking and NetworkManager revisions in any case.
Dropping sysctl.conf is probably not a solution, since that will leave us outta luck when it comes to changing settings of built-ins. Also, solving this during NetworkManager development is likely to only provide a solution for the net related stuff... Perhaps a solution needs to be implemented around modprobe, where by some sort of intelligence, modprobe would be able to apply the part of the sysclt.conf file that would touch the procnodes created by the modlue just loaded or something... This is probably an entirely new thing, but as far as I can see, it might be a decent solution, provided it can be made fast enough. It would give a single system-wide sysctl.conf (or whatever) with settings for the entire system... No need to worry about whether the module is loaded at sysctl call time etc...
Yes, I agree-having modprobe essentially do a sysclt -e -p is a fine plan (I think we discussed this on IRC last night). But - when a module is loaded on demand, that doesn't call modprobe, right? (or wrong?) I think that's what Bill was getting at when he mentioned udev. But I think we'd agree that settings in sysctl.conf being consulted whenever a module is loaded is the only sane way to implement sysctl.conf. The current was is confusing to the uninitiated. /me goes to read up about how kernel modules get loaded automatically.
It needs to be a selective sysctl -e -p, since we do not want it to override settings we, for whatever reason set manually for one module, when loading another. Sounds weird, so here's an example instead... My system is configured with net.ipv4.ip_forward = 0... But I'm plying with routing so I did an echo -n 1 >/proc/sys/net/ipv4/ip_forward to enable forwarding. Now I plug in my USB disk and modules gets loaded. It's really important that ip_forward is still "1" at this point, so we need to make module loading aware, somehow, of what procnodes are created during each module load. Perhaps, if this is something that we're going to follow through, it should be able to handle stuff outside of 'sys' as well?
... can't think of anything that "outside of 'sys'" would be good for, regarding this, though :)
(In reply to comment #7) > It needs to be a selective sysctl -e -p, since we do not want it to override > settings we, for whatever reason set manually for one module, when loading > another. Sounds weird, so here's an example instead... > My system is configured with net.ipv4.ip_forward = 0... But I'm plying with > routing so I did an echo -n 1 >/proc/sys/net/ipv4/ip_forward to enable > forwarding. Now I plug in my USB disk and modules gets loaded. It's really > important that ip_forward is still "1" at this point, so we need to make module > loading aware, somehow, of what procnodes are created during each module load. Yes, a valid point. Perhaps the heuristic needs to be: when loading a module, modprobe should (using sysctl or otherwise) look at sysctl.conf and set any values for entries created by the loading of this module, and disregard all others. sysctl -p would then serve the purpose of resetting all values to those in sysctl.conf, if needed by the user. > Perhaps, if this is something that we're going to follow through, it should be > able to handle stuff outside of 'sys' as well? Well - sysctl.conf is specific to /proc/sys (hence the name:) - isn't everything else just readonly?
not read-only but mostly debugging stuff and things that it doesn't make sense to touch with static values like this, so lets just drop that for now... Perhaps we should take this onto the devel forum and see what others think?
Sure - it's 1 am here right now, and I badly need sleep, so I'll leave that to you :) There's a thread over there already actually. Seems to me it would be a fairly straightforward patch to modprobe, transplanting some code from sysctl.
(In reply to comment #5) > Dropping sysctl.conf is probably not a solution, since that will leave us outta > luck when it comes to changing settings of built-ins. Incidentally - I think this part isn't true. For built ins, one can still setrelevant values with echo 1 > /proc/sys/foo/bar_baz (or sysctl /proc/sys/foo/bar_baz=1). Did I misunderstand? Actually, the more I think about it, the more I think sysctl should be deprecated - its functionality seems redundant.
sysctl gives a nice overview of the changes we want to make. It's entirely possible to live without it and echo stuff to the /proc filesystem directly. But it gives us a one-stop overview (the .conf file) of all our changes, rather than several initscripts that would each echo a lot of different things to a lot of different places (this is also needed as it is now, but dropping the sysctl functionality entirely would make it a lot worse, i think).
sysctl could output a file like sysctl.conf with all the parameters it couldn't set. All subsequent sysctl calls, which would sysctl.conf could instead only run the parameters from 'sysctl.conf.noyetapplied'. There may be a problem, where to store such a file on bootup, when '/' is not yet mounted writeable. I could think of a udev rule, or modprobe calling sysctl after module loading.
(In reply to comment #14) > sysctl could output a file like sysctl.conf with all the parameters it couldn't > set. All subsequent sysctl calls, which would sysctl.conf could instead only run > the parameters from 'sysctl.conf.noyetapplied'. There may be a problem, where to > store such a file on bootup, when '/' is not yet mounted writeable. > Yes - am not so keen on the writing a new file approach. I like the idea of a patch to modprobe which after module loading checks all entries in sysctl.conf for matches with the just loaded module's registered proc/sys entires. I need to look thru' the functions in linux/proc_fs.h to see what's available for that, though. This approach would remove any need for sysctl in the future. > I could think of a udev rule, or modprobe calling sysctl after module loading. I think the issue with using udev is that not all module loading corresponds to a udev (hardware) event - eg. the reason I originally noticed this inconsistency with sysctl.conf expected behaviour was because values were not being set as I hoped when loading conntrack modules.
udev gets uevents whenever modules are loaded. AFAIK, it doesn't *act* on them right now. It's certainly possible to write simple udev or modprobe rules that just frob a single setting.
Some discussion on this issue can be found here: http://lkml.org/lkml/2006/8/1/206
They appear to agree with us, that the solution is in userspace. We need a new modprobe feature essentially.
Yes indeed. I have been looking for a way to query what sysctl and/or sysfs (i.e. /proc) entries a module creates - so far to no avail. modinfo has no such functionality, and there are no clues in the source code. [sidenote: I am getting the feeling from reading the lkml archives that sysctls are being deprecated in favour of the sysfs nodes]