rancher / k3os

Purpose-built OS for Kubernetes, fully managed by Kubernetes.
https://k3os.io
Apache License 2.0
3.5k stars 397 forks source link

Some sysctl parameters are not applied #658

Open pvelati opened 3 years ago

pvelati commented 3 years ago

Version (k3OS / kernel) k3os version v0.11.1 5.4.0-48-generic #52 SMP Sat Sep 26 08:27:15 UTC 2020

Architecture x86_64

Describe the bug Some sysctl parameters are not applied when using cloud-config file for configuring the system.

To Reproduce Create a cloud-config.yaml file adding the following snippet and install k3os

k3os:
  sysctl:
    kernel.printk: "4 4 1 7"
    kernel.kptr_restrict: "1"
    net.core.somaxconn: "65535"
    vm.panic_on_oom: "1"

Expected behavior

$ sysctl -q kernel.printk net.core.somaxconn vm.panic_on_oom kernel.kptr_restrict
kernel.printk = 4       4       1       7
net.core.somaxconn = 65535
vm.panic_on_oom = 1
kernel.kptr_restrict = 1

Actual behavior

$ sysctl -q kernel.printk net.core.somaxconn vm.panic_on_oom kernel.kptr_restrict
kernel.printk = 1       4       1       7
net.core.somaxconn = 1024
vm.panic_on_oom = 0
kernel.kptr_restrict = 2

Additional context Virtualized on Proxmox, using pxe boot install (tested also with iso install). Tested also without "" for each parameters, same results. I don't know if there are other parameters that cannot be applied.

dweomer commented 3 years ago

k3OS sysctls are a little confusing and have some built-in overrides to be mindful of:

The entries in /etc/sysctl.d/*.conf get processed after k3os.sysctl entries, I believe.

I am pretty sure that I have changed kernel.printk via sysctls in config.yaml with success so it is possible that one of your values is failing to write correctly via our rudimentary processor: https://github.com/rancher/k3os/blob/v0.19.5-rc.1/pkg/sysctl/sysctl.go#L11-L20 (you would see an error about this in the boot console)

If a value write gets a low-level error it will prevent subsequent values from being written. Keep in mind that these sysctls are stored in a map by key which means the order in which the keys are process is not guaranteed. This may explain the kernel.printk and vm.panic_on_oom discrepancies.

If you want a sysctl override to stick, the latest boot-time binding you can get (aka avoiding possible system defaults) would be via run_cmd entries in config.yaml, i.e.:

run_cmd:
- sysctl -w 'kernel.printk=4 4 1 7'
- sysctl -w 'kernel.kptr_restrict=1'
- sysctl -w 'net.core.somaxconn=65535'
- sysctl -w 'vm.panic_on_oom=1'
pvelati commented 3 years ago

Thanks for the info @dweomer, tried on a new setup and it works well.

It seemed strange to me that in the example config.yaml I see some confs that are not working.

  sysctl:
    kernel.printk: "4 4 1 7"
    kernel.kptr_restrict: "1"
pvelati commented 3 years ago

I tried again with the new version of k3os: v0.20.4-k3s1r0 (I mean without the _runcmd part)

Expected behavior

$ sysctl -q kernel.printk net.core.somaxconn vm.panic_on_oom kernel.kptr_restrict
kernel.printk = 4       4       1       7
net.core.somaxconn = 65535
vm.panic_on_oom = 1
kernel.kptr_restrict = 1

Actual behavior

$ sysctl -q kernel.printk net.core.somaxconn vm.panic_on_oom kernel.kptr_restrict
kernel.printk = 4   4   1   7
net.core.somaxconn = 65535
vm.panic_on_oom = 0
kernel.kptr_restrict = 1

So for now is almost ok. Only _vm.panic_onoom is not taking the right config