From ArchWiki
Revision as of 20:11, 24 September 2013 by FrozenCow (Talk | contribs) ('sysctl -p' does not work)

Jump to: navigation, search

I can't imagine this being a very long article, but I do find it useful. I didn't have a clue what this command did until I came across it now. I recall it from my first time installing Arch, with regard to storing the volume levels in alsamixer. --Mustard 10:31, 22 October 2010 (EDT)

error: permission denied on key 'net.ipv4.conf.all.mc_forwarding'
error: permission denied on key 'net.ipv4.conf.default.mc_forwarding'

Are these not used any-more?

it's read only which might mean that it has to be changed while compiling the kernel, I'm not sure (it used to work), it is disabled by default anyway thestinger 16:39, 26 October 2010 (EDT)


From kernel doc:

tcp_rfc1337 - BOOLEAN
	If set, the TCP stack behaves conforming to RFC1337. If unset,
	we are not conforming to RFC, but prevent TCP TIME_WAIT
	Default: 0

So, isn't 0 the safe value? Our wiki says otherwise. -- Lahwaacz (talk) 08:56, 17 September 2013 (UTC)

With setting 0 the system would 'assassinate' a socket in time_wait prematurely upon receiving a RST. While this might sound like a good idea (it frees up a socket quicker), it opens the door for tcp sequence problems/syn replay. Those problems were described in RFC1337 and enabling the setting 1 is one way to deal with them (letting TIME_WAIT packets idle out even if a reset is received, so that the sequence number cannot be reused meanwhile). The wiki is correct in my view. Kernel doc is wrong here - "prevent" should read "enable". --Indigo (talk) 21:12, 17 September 2013 (UTC)

'sysctl -p' does not work

The tip about reloading the configuration with 'sysctl -p' does not work. Complains about missing file "/etc/sysctl.conf". Probably does not work after systemd not reading from /etc/sysctl.conf... olivervbk 23:12, 17 September 2013 (UTC-0300)

Do you have the /etc/sysctl.conffile replaced with a symlink to /etc/sysctl.d yet? I have not upgraded it yet. I was wondering about this edit as well. Was that proposed somewhere? I thought the systemd 207 brings the sysctl.d hierarchy to fix the settings. Usually its not a good idea to mod confs in /usr (as they will get lost not on reboots, but updates). edit: I just got the new package rolling in as well and see what you mean. I reverted your edit and changed the tip. Please see, if this works for you. --Indigo (talk) 20:05, 18 September 2013 (UTC)
Other questionable edits: [1], [2]. I've notified the user: User_talk:FrozenCow#sysctl.conf. -- Lahwaacz (talk) 17:18, 24 September 2013 (UTC)
Sorry people. I came across one instance of deprecated use of sysctl.conf and though I'd just replace all instances. sysctl -p worked for me, because I symlinked /etc/sysctl.conf to /etc/sysctl.d/99-sysctl.conf, like the sysctl page suggests. I saw the suggestion to put different functions into different files, so I've tried to do that in this instance (while also fixing the problem). Let me know whether things look good or not. --FrozenCow (talk) 18:12, 24 September 2013 (UTC)
This one is really nice ;) and thanks for the quick correction. What about using sysctl -p /etc/sysctl.d/* as an alternative to sysctl -p to apply all available options (i.e. not just one file)? Though I more like the idea of putting the necessary options into separate file (at least on this wiki) and specifying sysctl -p that_file. -- Lahwaacz (talk) 18:30, 24 September 2013 (UTC)
Yes, I thought of doing that too, but I was held back by the help entry of sysctl: -p, --load[=<file>] read values from file, which seemed to suggest it only takes a single file. I just tried your suggestion, but it does indeed work correctly (it reads multiple files). I'm not sure what the best way would be, but * does indeed do the same as what was on the wiki before.--FrozenCow (talk) 20:11, 24 September 2013 (UTC)