Difference between revisions of "Talk:Sysctl"

From ArchWiki
Jump to: navigation, search
('sysctl -p' does not work: re: rm'ed tip)
(added vfs_cache_pressure parameter: re)
 
(26 intermediate revisions by 8 users not shown)
Line 1: Line 1:
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. --[[User:Mustard|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 [[User:Thestinger|thestinger]] 16:39, 26 October 2010 (EDT)
 
 
 
== net.ipv4.tcp_rfc1337 ==
 
== net.ipv4.tcp_rfc1337 ==
  
Line 21: Line 12:
  
 
So, isn't {{ic|0}} the safe value? Our wiki says otherwise. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:56, 17 September 2013 (UTC)
 
So, isn't {{ic|0}} the safe value? Our wiki says otherwise. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 08:56, 17 September 2013 (UTC)
:With setting {{ic|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 {{ic|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".  --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:12, 17 September 2013 (UTC)
+
:With setting {{ic|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 {{ic|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. <s>Kernel doc is wrong here - "prevent" should read "enable".</s> --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 21:12, 17 September 2013 (UTC)
 +
 
 +
:Since this discussion is still open: An interesting attack to the kernels implementation of the related RFC5961 was published yesterday under [https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/cao cve2016-5696]. I have not looked into it enough to form an opinion whether leaving default {{ic|0}} or {{ic|1}} for this setting makes any difference to that, but it is exactly the kind of sequencing attack I was referring to three years back. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 08:38, 11 August 2016 (UTC)
 +
 
 +
== Virtual memory ==
 +
 
 +
The official documentation states that these two variables "Contain[s], as a percentage of total available memory that contains free pages
 +
and reclaimable pages,..." and that "The total available memory is not equal to total system memory.". However the comment underneath talks about them as if they were a percentage of ''system'' memory, making it quite confusing, e.g. I have 6GiB of system memory but only 1-2GiB available.
 +
 
 +
Also the defaults seem to have changed, I have {{ic|1=dirty_ratio=50}} and {{ic|1=dirty_background_ratio=20}}.
 +
 
 +
-- [[User:DoctorJellyface|DoctorJellyface]] ([[User talk:DoctorJellyface|talk]]) 08:27, 8 August 2016 (UTC)
 +
 
 +
:Yes, I agree. When I changed the section a little with [https://wiki.archlinux.org/index.php?title=Sysctl&type=revision&diff=435336&oldid=422169], I left the comment. The reason was that while it simplifies in current form, expanding it to show the difference between system memory and available memory first and only then calculate the percentages makes it cumbersome/complicated to follow. If you have an idea how to do it, please go ahead. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:07, 8 August 2016 (UTC)
 +
 
 +
::The problem is that the kernel docs don't explain what does "available memory" really mean. Assuming that it changes similarly to what {{ic|free}} shows, taking the system memory instead is still useful to prepare for the worst case. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 09:11, 8 August 2016 (UTC)
 +
 
 +
:::Yes, worst case also because "available" should grow disproportionately, because some slices, like system memory reserved for the bios or GPU will not change, regardless of total installed ram. I've had my go with [https://wiki.archlinux.org/index.php?title=Sysctl&type=revision&diff=445976&oldid=445672]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 07:54, 9 August 2016 (UTC)
 +
 
 +
== added vfs_cache_pressure parameter ==
  
 +
let me know if it's OK
 +
--[[User:NTia89|nTia89]] ([[User talk:NTia89|talk]]) 18:15, 26 December 2016 (UTC)
  
== 'sysctl -p' does not work ==
+
:Fine with me. Cheers. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 15:05, 27 December 2016 (UTC)
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... [[User:Olivervbk|olivervbk]] 23:12, 17 September 2013 (UTC-0300)
+
:Do you have the {{ic|/etc/sysctl.conf}}file replaced with a symlink to /etc/sysctl.d yet? <s>I have not upgraded it yet.</s> I was wondering about [https://wiki.archlinux.org/index.php?title=Sysctl&diff=275892&oldid=275542 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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:05, 18 September 2013 (UTC)
+
::Other questionable edits: [https://wiki.archlinux.org/index.php?title=Dropbox&diff=276501&oldid=275077], [https://wiki.archlinux.org/index.php?title=QEMU&diff=prev&oldid=276506]. I've notified the user: [[User_talk:FrozenCow#sysctl.conf]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. --[[User:FrozenCow|FrozenCow]] ([[User talk:FrozenCow|talk]]) 18:12, 24 September 2013 (UTC)
+
::::[https://wiki.archlinux.org/index.php?title=QEMU&diff=276544&oldid=276506 This one] is really nice ;) and thanks for the quick correction. What about using {{ic|sysctl -p /etc/sysctl.d/*}} as an alternative to {{ic|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 {{ic|sysctl -p ''that_file''}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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: {{ic|-p, --load[&#61;<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.--[[User:FrozenCow|FrozenCow]] ([[User talk:FrozenCow|talk]]) 20:11, 24 September 2013 (UTC)
+
::::::I added a sentence to explain the nature of processing of the individual files: [https://wiki.archlinux.org/index.php?title=Sysctl&diff=276600&oldid=276340]
+
::::::The reason I propose something like that is that using {{ic|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.
+
::::::--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:52, 25 September 2013 (UTC)
+
:::::::Even better, I've missed the {{ic|--system}} option of sysctl... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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: [https://wiki.archlinux.org/index.php?title=Sysctl&diff=276606&oldid=276602].
+
::::::::--[[User:Indigo|Indigo]] ([[User talk: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. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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 ([https://mailman.archlinux.org/pipermail/arch-dev-public/2013-September/025409.html]) and as {{ic|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. --[[User:Indigo|Indigo]] ([[User talk: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, [https://www.archlinux.org/news/deprecation-of-etcsysctlconf/] contains full instructions to migrate from {{ic|/etc/sysctl.conf}} to {{ic|/etc/sysctl.d/99-sysctl.conf}}, and so does the note at the beginning of [[sysctl#Configuration]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk: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. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:06, 26 September 2013 (UTC)
+

Latest revision as of 15:05, 27 December 2016

net.ipv4.tcp_rfc1337

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
	assassination.
	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)
Since this discussion is still open: An interesting attack to the kernels implementation of the related RFC5961 was published yesterday under cve2016-5696. I have not looked into it enough to form an opinion whether leaving default 0 or 1 for this setting makes any difference to that, but it is exactly the kind of sequencing attack I was referring to three years back. --Indigo (talk) 08:38, 11 August 2016 (UTC)

Virtual memory

The official documentation states that these two variables "Contain[s], as a percentage of total available memory that contains free pages and reclaimable pages,..." and that "The total available memory is not equal to total system memory.". However the comment underneath talks about them as if they were a percentage of system memory, making it quite confusing, e.g. I have 6GiB of system memory but only 1-2GiB available.

Also the defaults seem to have changed, I have dirty_ratio=50 and dirty_background_ratio=20.

-- DoctorJellyface (talk) 08:27, 8 August 2016 (UTC)

Yes, I agree. When I changed the section a little with [1], I left the comment. The reason was that while it simplifies in current form, expanding it to show the difference between system memory and available memory first and only then calculate the percentages makes it cumbersome/complicated to follow. If you have an idea how to do it, please go ahead. --Indigo (talk) 09:07, 8 August 2016 (UTC)
The problem is that the kernel docs don't explain what does "available memory" really mean. Assuming that it changes similarly to what free shows, taking the system memory instead is still useful to prepare for the worst case. -- Lahwaacz (talk) 09:11, 8 August 2016 (UTC)
Yes, worst case also because "available" should grow disproportionately, because some slices, like system memory reserved for the bios or GPU will not change, regardless of total installed ram. I've had my go with [2]. --Indigo (talk) 07:54, 9 August 2016 (UTC)

added vfs_cache_pressure parameter

let me know if it's OK --nTia89 (talk) 18:15, 26 December 2016 (UTC)

Fine with me. Cheers. --Indigo (talk) 15:05, 27 December 2016 (UTC)