Re: [HTCondor-users] why does htcondor change sysctl params, and why is this done outside of /etc/sysctl.{d, conf} ?

[Tom Downes <downes@xxxxxxx>]

On Fri, Aug 5, 2016 at 11:34 AM, Todd L Miller <tlmiller@xxxxxxxxxxx> wrote:

it's clear you're just blowing the settings out of the way even when they probably meet your needs.

    The default linux kernel tuning script checks before it changes /proc/sys/net/core/rmem_max (or anything else), and will only ever increase it, at least in my testing. This has been true since the tuning script has been introduced. If that part of the script isn't working for you, please contact me off-list so we can debug it; clearly shrinking any of these parameters isn't acceptable.

You're absolutely right. Not sure how I missed that.

# Not changing MAX_RECEIVE_BUFFER: new value (10383360) <= old value (16777216).

In any case, my puppet module will, every N minutes, actively revert any kernel parameters that it manages if they are not the value it expects. So, it wouldn't matter if you did. This is only true of kernel parameters that I tell Puppet about so I need to know which you're modifying and why. For the most part, it's not like I've really tested whether my (say) buffer settings are actually sensitive to 10MiB versus 16MiB, but there you are.

Â

(2) Clearer .conf file in /etc/sysctl.d about which kernel parameters it's
changing. You write names that you made up, not the actual kernel
parameters.

    I've added the name of the files in /proc that the script is changing. (The kernel parameter names are hopefully very similar if not identical, but we don't actually interact with that system at all.)

I believe there is overlap in kernel parameters and /proc files. I'm not sure it's 100%. e.g. /proc/sys/net/core/rmem_max andÂ/proc/sys/vm/swappiness.

Â

In this particular example of net.core.rmem_max, I believe the action is
not meaningful for TCP-based networks unless you also set net.ipv4.tcp_rmem
to a value that takes advantage of it. e.g. '4096 65536 16777216'.

    We're actually setting rmem_max so that we can have larger UDP buffers (so that the collector drops fewer updates on the floor).


    As for why we're doing it in a script and not in /etc/sysctl.*, I can think of three reasons off the top of my head:

(a) Not all of our supported systems do /etc/sysctl.*.
(b) Changes there don't take effect immediately. (Maybe a post-install
  script in the packaging could make the changes happen?)

sysctl -p filename would be the direct way of updating from specific files

Â

(c) Installs from tarballs shouldn't scale any worse than installations
  from the distribution's packaging system.

I do actually understand your reasoning for modifying kernel parameters and appreciate the compromises of various choices. The real upshot is that I go out of my way to manage kernel parameters -- pretty much any sysadmin needs to modify vm.swappiness out of the box -- and want to avoid clobbering.

Tom