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...)

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.

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 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.