grüß euch,

ich möchte mit einem systemd service ein script starten, welches mir ein paar kernel werte
ändert, leider startet systemd zu früh, so, daß die gesetzten werte vom kernel überschrieben werde.
wenn ich den service, später manuell starte, dann funktioniers wie gedacht, es funktiniert nich,,
wenn der service automatisch startet.

[Unit]
ConditionPathExists=/sys/kernel/debug/sched/tunable_scaling

[Service]
Type=idle
ExecStart=/usr/bin/sh -c '/usr/local/bin/kernel-tuning'
Restart=always
RestartSec=20

[Install]
WantedBy=multi-user.target

was muß ich anstellen, das systemd rechtzeitig den wert schreibt?

Du kannst unter [Unit] noch mit After und Wants definieren, nach welchem Service Deiner gestartet werden soll bzw. wovon er abhängt.

Sind die gewünschten Kernelwerte(also was du im Skript abfragst/setzt) per sysctl erreichbar?

Dann wäre es ggf. einfacher sysctl direkt zu nutzen, siehe:
man sysctl bzw. man sysctl.conf
sysctl ist eigentlich genau dafür gedacht.

Es gibt auch einen systemd-Service, der automatisch beim Boot startet und schon bestimmte Kernelwerte mittels sysctl setzt:
man systemd-sysctl.service
Aktuell veränderte Werte kannst du z.B. mittels:
systemd-analyze cat-config sysctl.d
sehen.
Da würde sich ggf. anbieten halt eine brikler.conf z.B. nach /etc/sysctl.d zu legen mit deinen Werten.

Zum Hinweis von @hcjl :
Evtl ist genau o.a. systemd.service das "Passende" für After/Wants.

via sysctl wäre eine feine sache, und ich wäre auch absolut zufrieden damit 🙂


echo        0 | sudo tee /sys/kernel/debug/sched/tunable_scaling
		echo 16000000 | sudo tee /sys/kernel/debug/sched/latency_ns
		echo 1600000  | sudo tee /sys/kernel/debug/sched/min_granularity_ns
		echo  9600000 | sudo tee /sys/kernel/debug/sched/wakeup_granularity_ns

…aber wie erwische ich das?

es handelt sich um einen selbst gebauten kernel mit bore scheduler, die standart einstellung fühlt sich schon gut an, aber vielleicht lässt sich noch bissl was raus kitzeln 🙂

  • GerBra hat auf diesen Beitrag geantwortet.

    brikler …aber wie erwische ich das?

    Wohl nicht per sysctl, bei mir ist z.B:
    /sys/kernel/debug/sched/latency_ns
    auch nicht per sysctl abfragbar/setzbar
    (Wenn für deine Shell autocompletion verfügbar ist kannst du per:
    sysctl kernel.sched<TAB><TAB>
    dich "durchhangeln", oder du schaust in /proc/sys, da sind die Werte drin die per sysctl verwaltet werden können).

    Bleibt also wohl nur der Ansatz "echo irgendwas >nach/irgendwo", wie du es im Skript hast (ekelhaftes sudo...)

    Versuche mal wie ich oben schrieb deinen Service (das ist doch ein System Service und kein USer-Service?) per After nach dem systemd-sysctl.service zu starten. Ob es prinzipiell funtionieren würde könntest du ja z.B. so austesten in dem du per Skript kernel.sysrq ausschaltest (wenn sysrq bei dir eingeschaltet ist).

    sysctl kernel.sysrq 
         kernel.sysrq = 1

    Da könntest du jetzt mal in deinem Skript eine 0/Null rein "echoen" und schauen, ob das "Timing" funktioniert, der Wert also auf 0 bleibt.
    echo "0" > /proc/sys/kernel/sysrq
    Wenn es prinzipiell funktioniert mit deinem Service/Script dann kannst du ja mit den "richtigen" scheduler Werten versuchen.

    • brikler hat auf diesen Beitrag geantwortet.

        GerBra systemd

        leider mags so nicht 🙁

        [Unit]
Description=Adjust latency timers for PCI peripherals
#ConditionPathExists=/sys/kernel/debug/sched/wakeup_granularity_ns
ConditionPathExists=/sys/kernel/debug/sched/tunable_scaling
After=systemd-sysctl.service

[Service]
Type=idle
#Type=oneshot
ExecStart=/usr/bin/sh -c '/usr/local/bin/kernel-tuning'
Restart=always
RestartSec=20

[Install]
WantedBy=multi-user.target
        • GerBra hat auf diesen Beitrag geantwortet.

            Und was sagt das Log dazu?
            Wird dein Service denn ausgeführt?

            //Edit: laß ggf. mal die Endung .service weg beim After=
            Ich weiß nicht ob nicht nur der Unit-Name gefordert ist.

            Hilfreich ggf:

            systemctl status dein_service
systemd-analyze blame 
systemd-analyze verify dein_service_unit_file
systemd-analyze critical-chain

            Das sind doch Werte, die du nur einmal setzt.
            Falls du mit einem Service nicht hinkriegst mache es zur Not über sowas wie Shell-Profile oder Autostart vom WM oder whatever...

            (Die /etc/rc.local war schon eine schöne Sache damals...)

              GerBra Falls du mit einem Service nicht hinkriegst mache es zur Not über sowas wie Shell-Profile oder Autostart vom WM oder whatever...

              (Die /etc/rc.local war schon eine schöne Sache damals...)

              mit einem timer könnte es funktionieren, und ich vermisse die /etc/tc.local 🙂

                GerBra (Die /etc/rc.local war schon eine schöne Sache damals...)

                Ich glaube, da sprichst Du vielen aus der Seele. Aus Gründen der Nostalgie möchte ich auch noch die /etc/rc.conf erwähnen ;-)

                  brikler leider mags so nicht 🙁

                  Bei mir schon ;-)

                  
# ls -l /usr/local/bin/kernel-tuning 
-rwxr-xr-x 1 root root 112  6. Jul 13:07 /usr/local/bin/kernel-tuning

# cat /usr/local/bin/kernel-tuning 
# Latency
echo 22000666 > /sys/kernel/debug/sched/latency_ns

# cat /etc/systemd/system/gb-kernel-settings.service 
[Unit]
Description=Adjust kernel latency
#ConditionPathExists=/sys/kernel/debug/sched/tunable_scaling
#After=systemd-sysctl

[Service]
# Type=idle
Type=oneshot
ExecStart=/usr/bin/sh -c '/usr/local/bin/kernel-tuning'
#Restart=always
#RestartSec=20

[Install]
WantedBy=multi-user.target

                  Nach dem Boot

                  # cat /sys/kernel/debug/sched/latency_ns 
22000666

                  systemd-analyze critical-chain gb-kernel-settings.service
                  und
                  systemd-analyze plot > /tmp/plot.svg
                  zeigen auch, daß mein Service ohne besondere Konfiguration (Condition* oder After/Wants) erst nach dem sysinit.target ausgeführt wird, also nicht kollidieren würde mit z.B. dem systemd-sysctl.service.

                      GerBra das war mal wieder hervorragende arbeit! dank dem, funktioniert es jetzt 🙂

                        Ist halt die Frage, warum es vorher nicht funktionierte.
                        Wenn dein Spieltrieb noch groß ist, kannst du ja mal verschiedene deiner Konfigs aus dem ursprünglichen Setup aus Post #1 versuchen und schauen, was wann warum evtl. nicht mehr "funzt"

                        Als da wären:

                        • Im Unit das mit der Condition
                        • Diese Restart-Geschichte
                        • und (meine Vermutung) das mit der sudo-Pipe-Geschichte im Skript.
                          (Es könnte wg. dem sudo ein Unterschied sein, ob du den Service händisch startest oder ob es während des Init sein soll. Das sudo darin ist IMHO eh "blödsinnig", ich verstehe zwar den Grund aber warum zum Testen als User nicht das ganze Skript mittels sudo ausführen?)
                        • brikler hat auf diesen Beitrag geantwortet.

                          GerBra Ist halt die Frage, warum es vorher nicht funktionierte.ee

                          ich hatte einige service files maskiert, dies mochte dieser service nicht, aber systemd unmask erledigte das problem 🙂

                          danke für die hilfe 🙁

                          • GerBra hat auf diesen Beitrag geantwortet.

                              brikler ich hatte einige service files maskiert, dies mochte dieser service nicht

                              ;-)

                              Bei deinen "Experimenten" mit dem "ungeliebtem"(ich teile das!) systemd:
                              Schon mal über eine virtuelle Maschine als Testumgebung nachgedacht?
                              Oder für dich ggf. sogar zwei:

                              • eine total "Vanilla"
                                (zum Austesten von genau EINER Sache und wieder rückgängig machen)
                              • und eine zum "Hacken"
                                (Bevor du "Dinge" auf deine reale Maschine(n) losläßt)

                              Ich persönlich nutze auch eine zum Austesten gerade "systemrelevanter" Dinge.

                              Und (heißer Tip!, gratis):
                              Gewöhne dir an, ein Changelog deiner Maschine(n) zu führen. Z.B. über solche Dinge wie massakrierte(oder maskierte) Services u.ä. Ich nutze dafür die Tagebuch-Funktion von zim(da ich das sowieso intensiv nutze), aber jeder andere Ansatz, der einfach zu erstellen/durchsuchen/nachzuvollziehen ist, wäre sinnvoll IMHO. Spätestens wenn du das mal "professionell" machen mußt/willst kommst du um Dokumentation nicht herum.
                              //Edit: der erste Eintrag deinerseits in so einen "Workflow" könnte nun sein, daß du diesen neuen Service dokumentierst. Am besten mit dem Unit-File und dem Skript, z.B. einen Link auf diesen Thread, Doku (Browsertab-Links) die du für den Vorgang relevant hältst, und ggf. ein syslog wie es "richtig" aussieht. Also alles, damit du (und im Team andere) so eine Änderung auch in einem halben Jahr noch nachvollziehen/beachten könnten.

                              //Edit2:

                              brikler ich hatte einige service files maskiert, dies mochte dieser service nicht

                              Hätte dann dein ganz urspünglicher Ansatz auch funktioniert bzw. nutzt du den jetzt? Wäre noch mal interessant.

                                    GerBra Gewöhne dir an, ein Changelog deiner Maschine(n) zu führen

                                    du weißt doch wie das ist: die dokumentation schreibt man wenn man fertig ist, und dann…
                                    ich fürchte, da wird meine selbstdisiplin nicht ganz reichen, allerdings, wenn ich was ändere, und gefundene werte verwende, kommt da auch immer die quelle mit dazu.

                                    GerBra Hätte dann dein ganz urspünglicher Ansatz auch funktioniert bzw. nutzt du den jetzt? Wäre noch mal interessant.

                                    es hätte funktioniert, wenn mein service nicht ein wenig zu früh ausgeführt worden wäre und das unmask sorgte dafür, daß systemd eben diese kleinigkeit länger braucht, bevor er meinen service startet

                                    • tuxnix hat auf diesen Beitrag geantwortet.

                                          brikler die dokumentation schreibt man wenn man fertig ist

                                          Ich mache das mittlerweile anders. Der Editor den ich nutze (kate) kann auch Markdown.
                                          Da mache ich einen neuen Notizzettel auf und kopiere mir Meldungen, Befehle die ich brauche und vorläufige Konfigurationen parallel während ich an etwas bastele einfach hin.
                                          Je nachdem um was es geht, wird die Notiz später einfach gelöscht, dient dazu nach Wochen das Ganze noch mal aufzugreifen oder entwickelt sich im Laufe der Zeit zu einer Dokumentation oder Anleitung.