From ArchWiki
Revision as of 13:06, 26 September 2013 by Indigo (talk | contribs) ('sysctl -p' does not work: re: rm'ed tip)
Jump to navigation Jump to 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)
I added a sentence to explain the nature of processing of the individual files: [3]
The reason I propose something like that is that using sysctl -p /etc/sysctl.d/* omits any (default) parameters in /usr/lib/sysctl.d/ files, so it would be kind of incomplete. The symlink which lead to this discussion initially is not harmful, but actually just compensates sysctl not finding the legacy file when no file is specified. (I reckon they will change the bin sometime). Maybe the tip itself could be expanded to note that singular configuration files can be processed too.
--Indigo (talk) 14:52, 25 September 2013 (UTC)
Even better, I've missed the --system option of sysctl... -- Lahwaacz (talk) 15:16, 25 September 2013 (UTC)
I found that option recently only too, after this made Arch front page news. Pretty useful though. I just wanted to add a word to my last edit and ended up adding your suggestion right with it, just makes sense to name "-p" there rather than in the tip at the end: [4].
--Indigo (talk) 17:10, 25 September 2013 (UTC)
Agreed; I think that now the tip at the end can be removed - our wiki should not instruct to create symlinks to deprecated config files. -- Lahwaacz (talk) 17:35, 25 September 2013 (UTC)
Well, the symlink was added last week following Olivervbk's observation that the "-p" option does not work anymore. It's the official legacy work-around ([5]) and as man sysctl indicates, the deprecation is not complete yet. The only harm it does is applying 99-sysctl.conf twice when sysctl is called explicitly. Why not keep it now that users may still look into migrating whatever sysctl.conf.pacsave. --Indigo (talk) 23:50, 25 September 2013 (UTC)
I take it that the systemd changelog is a recommendation/suggestion for packagers rather than end users. Anyway, [6] contains full instructions to migrate from /etc/sysctl.conf to /etc/sysctl.d/99-sysctl.conf, and so does the note at the beginning of sysctl#Configuration. -- Lahwaacz (talk) 05:43, 26 September 2013 (UTC)
True. I'm convinced now. It's more up to sysctl displaying an appropriate error message. I purged the tip. Thanks for discussing it. --Indigo (talk) 13:06, 26 September 2013 (UTC)