Bug 312481 - sysctl.conf settings not "sticking" at boot
Summary: sysctl.conf settings not "sticking" at boot
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 7
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-29 17:20 UTC by Jonathan Underwood
Modified: 2014-03-17 03:08 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-10-01 19:56:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jonathan Underwood 2007-09-29 17:20:57 UTC
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

Comment 1 Jonathan Underwood 2007-09-30 20:45:10 UTC
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.

Comment 2 Jonathan Underwood 2007-09-30 20:49:17 UTC
Reassigned to initscripts maintainer.

Comment 3 Bill Nottingham 2007-10-01 19:56:23 UTC
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.

Comment 4 Jonathan Underwood 2007-10-01 22:24:32 UTC
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.

Comment 5 Thomas M Steenholdt 2007-10-01 23:08:52 UTC
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...

Comment 6 Jonathan Underwood 2007-10-01 23:22:22 UTC
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.

Comment 7 Thomas M Steenholdt 2007-10-01 23:42:12 UTC
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?

Comment 8 Thomas M Steenholdt 2007-10-01 23:51:31 UTC
... can't think of anything that "outside of 'sys'" would be good for, regarding
this, though :)

Comment 9 Jonathan Underwood 2007-10-02 00:00:22 UTC
(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?

Comment 10 Thomas M Steenholdt 2007-10-02 00:02:28 UTC
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?

Comment 11 Jonathan Underwood 2007-10-02 00:11:29 UTC
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.

Comment 12 Jonathan Underwood 2007-10-02 00:22:24 UTC
(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.

Comment 13 Thomas M Steenholdt 2007-10-02 00:53:14 UTC
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).

Comment 14 Harald Hoyer 2007-10-02 11:11:38 UTC
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.

Comment 15 Jonathan Underwood 2007-10-02 11:33:42 UTC
(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.

Comment 16 Bill Nottingham 2007-10-02 21:21:46 UTC
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.

Comment 17 Jonathan Underwood 2007-10-05 16:57:22 UTC
Some discussion on this issue can be found here:

http://lkml.org/lkml/2006/8/1/206



Comment 18 Thomas M Steenholdt 2007-10-05 17:36:23 UTC
They appear to agree with us, that the solution is in userspace. We need a new
modprobe feature essentially.

Comment 19 Jonathan Underwood 2007-10-05 19:05:52 UTC
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]


Note You need to log in before you can comment on or make changes to this bug.