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.