# Dynamic Tuning: Den Kernel im laufenden Betrieb biegen

TL;DR / Management Summary Ein Senior Admin startet einen Server nicht neu, um einen Parameter zu ändern. Er nutzt sysctl oder schreibt direkt in das virtuelle /proc/sys/ Dateisystem. In diesem Modul lernen wir die Hierarchie der Konfigurationsdateien kennen, verstehen die Lade-Reihenfolge unter SLES und Arch und automatisieren die Verteilung von Tuning-Parametern auf hunderte Server, ohne die Stabilität zu gefährden.

# 1. Einführung & Architektur

Die Schnittstelle zum RAM.

sysctl ist lediglich ein Frontend für das /proc/sys/ Verzeichnis. Jede Datei dort entspricht einem Kernel-Parameter.

# Die Management-Ebenen (Mermaid)

graph LR
    A[Admin / Script] -->|sysctl -w| B[Kernel API]
    A -->|echo >| C[/proc/sys/...]
    B --> D[Active Kernel Memory]
    C --> D
    subgraph "Persistence"
        E[/etc/sysctl.d/*.conf] -->|boot / sysctl --system| B
        F[/etc/sysctl.conf] -->|legacy| B
    end

# 2. Die Hierarchie der Konfiguration

Wer überschreibt wen?

Systemd lädt die Konfigurationen beim Booten in einer festen Reihenfolge:

1. /usr/lib/sysctl.d/*.conf (Distributions-Standards)
2. /etc/sysctl.d/*.conf (Admin-Anpassungen - Hier arbeiten wir!)
3. /etc/sysctl.conf (Veraltet, aber oft noch vorhanden)

# 3. Runtime Manipulation

Änderungen ohne Files.

# Den Hebel sofort umlegen

# Setzt den Parameter sofort aktiv (bis zum nächsten Reboot)
sudo sysctl -w net.ipv4.ip_forward=1

# Direkter Weg via Filesystem (identisch)
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

# Konfiguration neu laden

# Lädt alle Dateien in der korrekten Hierarchie neu
sudo sysctl --system

# 4. Day-2 Operations: Flotten-Management

Automation mit Ansible.

In großen Umgebungen nutzen wir das sysctl Modul von Ansible, das sich um die Persistenz kümmert.

- name: Optimize swappiness
  ansible.posix.sysctl:
    name: vm.swappiness
    value: '10'
    state: present
    reload: yes

# 5. Troubleshooting & “War Stories”

Wenn die Werte zurückspringen.

# Story 1: “Der ignorierte Parameter”

Symptom: Der Admin schreibt net.core.somaxconn = 4096 in die /etc/sysctl.conf, aber nach dem Reboot zeigt sysctl net.core.somaxconn wieder den alten Wert 128. Ursache: Eine Datei unter /etc/sysctl.d/ (z.B. vom Hardware-Hersteller oder einer Applikation) wird später geladen und überschreibt die sysctl.conf. Lösung: Nutzen Sie sysctl --system, um zu sehen, welche Files geladen werden. Verschieben Sie Ihre Änderung in eine Datei mit hohem Präfix (z.B. 99-custom.conf).

# Story 2: “Der Read-Only Fehler”

Symptom: sysctl -w kernel.threads-max=1000 schlägt mit Permission Denied fehl, obwohl man Root ist. Ursache: Manche Parameter sind “Read-Only” nach dem Booten oder hängen von anderen Einstellungen ab (z.B. wenn der Kernel im Lockdown-Modus läuft, siehe Artikel 371). Lösung: Prüfen Sie, ob der Parameter via Boot-Option (GRUB) gesetzt werden muss oder ob das System-Hardening die Änderung zur Laufzeit verbietet.

# 6. Fazit & Empfehlung

• Organisation: Nutzen Sie ausschließlich /etc/sysctl.d/ für Ihre Änderungen.
• Validierung: Prüfen Sie nach jeder Änderung den Effekt: sysctl <parameter>.
• Wahl: Nutzen Sie sysctl Befehle in Skripten, anstatt direkt in /proc/sys/ zu schreiben – es ist sicherer und bietet bessere Fehlermeldungen.

# Anhang: Cheatsheet