Temperaturgesteuerte Prozesssteuerung mit bash

[Yadgar]

Hi(gh)!

Nachdem ich entdeckt habe, dass psensor auch im Konsolenmodus arbeitet, bin ich auf die Idee gekommen, meine Video-Rendering-Sessions mit kdenlive fortan automatisch zu steuern, indem ein bash-Skript genau das tut, was ich bis jetzt von Hand gemacht habe:

Nach dem Starten von kdenlive (via Konsole) und des Rendering-Processes ("melt"):

1. anhand der Ausgabe von ps -aux die Nummer des melt-Prozesses ermitteln

2. Solange dieser Prozess existiert:

2.1. sekündlich mit psensor die CPU-Temperatur auslesen

2.2. Sobald die Temperatur 83°C erreicht:

2.3. kill -SIGSTOP <melt-Prozessnummer>

2.4. Sobald die Temperatur 30°C erreicht:

2.5. kill -SIGCONT <melt-Prozessnummer>

3. Programmende

Jetzt die erste Frage: wie lese ich in bash aus einem Ausgabe-Stream eine Zeile nach Suchkriterium aus (das wäre die Zeile mit dem "melt"-Prozess in der Ausgabe von ps -aux)?

[DeletedUserReAsG]

1. anhand der Ausgabe von ps -aux die Nummer des melt-Prozesses ermitteln
[…]
Jetzt die erste Frage: wie lese ich in bash aus einem Ausgabe-Stream eine Zeile nach Suchkriterium aus (das wäre die Zeile mit dem "melt"-Prozess in der Ausgabe von ps -aux)?

Könnte man mit grep und cut machen. Kann man sich aber sparen: pidof gibt die PID direkt aus.

[schorsch_76]

pgrep macht das auch.

[MSfree]

Und mit

Code: Alles auswählen

cat /sys/devices/platform/coretemp.0/hwmon/hwmon1/temp?_input | sort | tail -1

bekommt man die höchste Temperatur aller Cores im System in einer einzigen Zahl geliefert. Der Wert ist allerdings in Miligrad, man muß ihn durch 1000 teilen, um °C zu bekommen.

[JTH]

Man kann sich die Suche nach der PID auch sparen und sich die einfach direkt nach dem Aufruf merken:

Code: Alles auswählen

#!/bin/sh

# Ausgabe "Terminated" am Ende vermeiden
trap exit TERM

# Killt dieses aufrufende Skript und damit folgende Temperaturkontrolle, sobald melt fertig ist
{ melt ...; kill $$; } &
melt_pid=$!

while :; do
        # Temperatur checken, mit kill -sSTOP/CONT $melt_pid hantieren
        sleep 1
done

(Kann und sollte man bestimmt noch verfeinern, damit z.B. ein SIGINT noch sinnvolleres tut.)

[Yadgar]

Hi(gh)!

Und mit

Code: Alles auswählen

cat /sys/devices/platform/coretemp.0/hwmon/hwmon1/temp?_input | sort | tail -1

bekommt man die höchste Temperatur aller Cores im System in einer einzigen Zahl geliefert. Der Wert ist allerdings in Miligrad, man muß ihn durch 1000 teilen, um °C zu bekommen.

Dieses Verzeichnis gibt es bei mir nicht, wahrscheinlich, weil das entsprechende Programm nicht installiert ist. Wie heißt das Paket?

[Tintom]

Eventuell heißt es leicht anders bei dir. Zeig' mal die Ausgabe von
find /sys/devices/platform/ -name hwmon

[Yadgar]

Hi(gh)!

1. anhand der Ausgabe von ps -aux die Nummer des melt-Prozesses ermitteln
[…]
Jetzt die erste Frage: wie lese ich in bash aus einem Ausgabe-Stream eine Zeile nach Suchkriterium aus (das wäre die Zeile mit dem "melt"-Prozess in der Ausgabe von ps -aux)?

Könnte man mit grep und cut machen. Kann man sich aber sparen: pidof gibt die PID direkt aus.

Das funktioniert schon einmal! Nächstes Problem: wenn ich die Manpage zu pidof richtig verstanden habe, gibt pidof bei einem nicht existierenden Prozess 0 zurück. Wenn ich das jetzt in einem while-Schleifenkopf prüfen will:

Code: Alles auswählen

while [ $(pidof -s melt) -ne 0 ]

bekomme ich die Fehlermeldung: ./hg.sh: Zeile 3: [: -ne: Einstelliger (unärer) Operator erwartet.

Was mache ich falsch?

[Yadgar]

Hi(gh)!

Eventuell heißt es leicht anders bei dir. Zeig' mal die Ausgabe von
find /sys/devices/platform/ -name hwmon

Diesen Threadzweig können wir beenden, da ich mich für die Lösung mit pidof entschieden habe!

[JTH]

Code: Alles auswählen

while [ $(pidof -s melt) -ne 0 ]

bekomme ich die Fehlermeldung: ./hg.sh: Zeile 3: [: -ne: Einstelliger (unärer) Operator erwartet.

Dein pidof-Aufruf hat nix gefunden, deshalb stand in der Zeile effektiv

Code: Alles auswählen

while [  -ne 0 ]

Die Möglichkeit, dass pidof nix findet, musst du mit abdecken.

Ich verweis nochmal auf meinen Einwurf oben, der hat das PID-Gesuche in einer Zeile abgefrühstückt

Code: Alles auswählen

melt_pid=$!

[Livingston]

Code: Alles auswählen

while [ $(pidof -s melt) -ne 0 ]

bekomme ich die Fehlermeldung: ./hg.sh: Zeile 3: [: -ne: Einstelliger (unärer) Operator erwartet.

Dein pidof-Aufruf hat nix gefunden, deshalb stand in der Zeile effektiv

Code: Alles auswählen

while [  -ne 0 ]

Die Möglichkeit, dass pidof nix findet, musst du mit abdecken.

Ich verweis nochmal auf meinen Einwurf oben, der hat das PID-Gesuche in einer Zeile abgefrühstückt

Code: Alles auswählen

melt_pid=$!

@Yadgar: Wenn pidof nix findet ist der Return-Code Null, es erfolgt aber keine Ausgabe über den Standard-Ausgang. Um den Fall einer leeren Ausgabe abzufangen, kannst Du einfach Anführungszeichen um den potentiellen Delingquenten packen:

Code: Alles auswählen

while [ "$(pidof -s melt)" -ne "0" ]

Konkret wird in diesem Fall daraus: "" -ne "0"

[Yadgar]

Hi(gh)!

@Yadgar: Wenn pidof nix findet ist der Return-Code Null, es erfolgt aber keine Ausgabe über den Standard-Ausgang. Um den Fall einer leeren Ausgabe abzufangen, kannst Du einfach Anführungszeichen um den potentiellen Delingquenten packen:

Code: Alles auswählen

while [ "$(pidof -s melt)" -ne "0" ]

Konkret wird in diesem Fall daraus: "" -ne "0"

Nein, funktioniert auch nicht - ich bekomme jetzt die Fehlermeldung: ./hg.sh: Zeile 3: [: : Ganzzahliger Ausdruck erwartet.

[JTH]

-ne vergleicht Zahlen. Ein leerer String – "" – kann nicht mit einer Zahl – 0 – verglichen werden. Dafür müsstest du den =-Operator nehmen und die Quotes um den $(pidof …)-Aufruf beibehalten.

Nachtrag: Es ist auch unsinnig, die Ausgabe von pidof mit der 0 zu vergleichen. Es gibt nämlich keine PID 0, die starten bei 1. Den Rückgabewert, also den Erfolg oder Misserfolg des Aufrufs, überprüft man anders. Dafür kannst du einfach das [ ... ] durch den pidof-Aufruf ersetzen.

[Livingston]

Ups, "mal eben" einen Fehler beheben, und schon haue ich den nächsten rein.
Wie auch immer: JTHs Ansatz mit melt_pid=$! ist ohnehin eleganter.

[JTH]

Ups, "mal eben" einen Fehler beheben, und schon haue ich den nächsten rein.

Das -ne hattest du ja nicht vorgeschlagen

[Yadgar]

Hi(gh)!

Den Rückgabewert, also den Erfolg oder Misserfolg des Aufrufs, überprüft man anders. Dafür kannst du einfach das [ ... ] durch den pidof-Aufruf ersetzen.

Das stimmt nicht ganz... wenn ich die eckigen Klammern weglasse und einfach schreibe

Code: Alles auswählen

while $(pidof -s melt)
do
  echo "melt ist aktiv!"
done

kommt die Fehlermeldung: ./hg.sh: Zeile 3: 3629: Kommando nicht gefunden.

Setze ich den pidof-Aufruf aber in eckige Klammern und starte ein Test-Rendering in kdenlive, wird tatsächlich solange dieses Testrendering läuft "melt ist aktiv!" ausgeben, nach dem Abbruch dann nicht mehr - also genau so, wie es sein soll! Danke für den Tipp!

[Yadgar]

Hi(gh)!

Eventuell heißt es leicht anders bei dir. Zeig' mal die Ausgabe von
find /sys/devices/platform/ -name hwmon

Leerstring, bzw. rein gar nichts!

[MSfree]

Eventuell heißt es leicht anders bei dir. Zeig' mal die Ausgabe von
find /sys/devices/platform/ -name hwmon

Leerstring, bzw. rein gar nichts!

Das /sys-Dateisystem stellt der Kernel bzw. die Kernelmodule zur Verfügung. Da du einen AMD-Prozessor hast, sind die Temperatursensoren möglicherweise in einem anderen Verzeichnis als bei meinem Intel. Ich würde mal nach "temp" suchen:

Code: Alles auswählen

find /sys | grep -i temp

Bei mir heißen die temp0_input bis tempX_input (je nach Anzahl CPU-Kerne) und liegen in /sys/devices/platform/coretemp.0/hwmon/hwmon2.

Ich finde es halt bequemer, die Temperaturen von da zu holen statt eine Ausgabe von psensors auszuwerten.

[JTH]

Den Rückgabewert, also den Erfolg oder Misserfolg des Aufrufs, überprüft man anders. Dafür kannst du einfach das [ ... ] durch den pidof-Aufruf ersetzen.

Das stimmt nicht ganz... wenn ich die eckigen Klammern weglasse und einfach schreibe

Code: Alles auswählen

while $(pidof -s melt)
do
  echo "melt ist aktiv!"
done

kommt die Fehlermeldung: ./hg.sh: Zeile 3: 3629: Kommando nicht gefunden.

Hätte ich vielleicht klarer schreiben sollen. Die Command-Substitution $( … ) gehört nicht zum Aufruf. Ich meinte Folgendes:

Code: Alles auswählen

while pidof -s melt >/dev/null
do
  echo "melt ist aktiv!"
done

Mit Umleitung nach /dev/null, damit nicht ständig eine PID ausgegeben wird.

[Yadgar]

Hi(gh)!

Das /sys-Dateisystem stellt der Kernel bzw. die Kernelmodule zur Verfügung. Da du einen AMD-Prozessor hast, sind die Temperatursensoren möglicherweise in einem anderen Verzeichnis als bei meinem Intel. Ich würde mal nach "temp" suchen:

Code: Alles auswählen

find /sys | grep -i temp

Bei mir heißen die temp0_input bis tempX_input (je nach Anzahl CPU-Kerne) und liegen in /sys/devices/platform/coretemp.0/hwmon/hwmon2.

Bei mir gibt es /sys/devices/pci0000:00/0000:00:18.3/hwmon/hwmon1/ und /sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/hwmon/hwmon0/ ... die für mich relevante CPU-Temperatur steht - laut Vergleich mit psensor - in hwmon1/temp1_input (hwmon0/temp1_input zeigt die Festplatten-Temperatur an). Hmmmmmm...

Code: Alles auswählen

t=$(pidof -s melt)

cd /sys/devices/pci0000:00/0000:00:18.3/hwmon/hwmon1
run=1 # Flag für Render- (1) und Abkühlphase (0)

while [ $(pidof -s melt) ]
do
  tm=$(cat temp1_input)
  tm=$((tm/1000))
  echo "CPU: "$tm"°C"
  sleep 1
  if [ $run -eq 1 ]
  then
    if [ $tm -eq 75 ]
    then
      kill -SIGSTOP $t
      echo "Renderprozess angehalten!"
      run=0
    fi
  fi
  if [ $run -eq 0 ]
  then
    if [ $tm -eq 30 ]
    then
      kill -SIGCONT $t
      echo "Renderprozess fortgesetzt!"
      run=1
    fi
  fi
done

...es funktioniert!!! Ich habe die zulässige Höchsttemperatur auf 75 statt 83 Grad gesetzt, weil es im Moment hier nicht heiß genug ist, um das Programm mit der definitiven Abschaltetemperatur testen zu können...

Danke für Eure Tipps!

Eine letzte Frage hätte ich noch: wie kann ich die Schrift der Ausgabe unterschiedlich einfärben? Ich fände es praktischer, wenn ich Render- und Abkühlphase gleich an der Schriftfarbe der Temperaturmeldungen erkennen könnte...

[JTH]

Du solltest die Temperaturvergleiche noch von -eq (ist gleich) zu -ge (größer oder gleich) bzw. -le (kleiner oder gleich) ändern. Sonst wird deine CPU weiter gegrillt, wenn die Temperatur beim Vergleich schon bei 76°C oder mehr angekommen war. Und auf der anderen Seite ginge es nie weiter, wenn die Temperatur schon auf 29°C gesunken wäre.

wie kann ich die Schrift der Ausgabe unterschiedlich einfärben?

Siehe z.B. https://www.shellhacks.com/bash-colors/

[MSfree]

Code: Alles auswählen

t=$(pidof -s melt)

cd /sys/devices/pci0000:00/0000:00:18.3/hwmon/hwmon1
run=1 # Flag für Render- (1) und Abkühlphase (0)

while [ $(pidof -s melt) ]
do
  tm=$(cat temp1_input)
  tm=$((tm/1000))
  echo "CPU: "$tm"°C"
  sleep 1
  if [ $run -eq 1 ]
  then
    if [ $tm -eq 75 ]
    then
      kill -SIGSTOP $t
      echo "Renderprozess angehalten!"
      run=0
    fi
  fi
  if [ $run -eq 0 ]
  then
    if [ $tm -eq 30 ]
    then
      kill -SIGCONT $t
      echo "Renderprozess fortgesetzt!"
      run=1
    fi
  fi
done

Ich würde nicht mit cd in das Verzeichnis wechseln, wo sich die Sensorwerte befinden. Die Pseudodateien kann man auch mit absolutem Pfad auslesen.

Abgesehen von JTHs Einwand, auf größer/gleich bzw. kleiner/gleich zu testen, befinden sich im /sys-Dateisystem noch weitere nützliche Dateien. Dort sind auch (irgendwo) die minimale, maximale und aktuelle CPU-Frequenz abgelegt. Statt deine Prozesse anzuhalten könntest du auch eine temperaurabhängige Frequenzanpassung bauen, die erstmal versucht, die Temperaturen durch runtertakten im Zaum zu halten und nur als letzte Notfallmaßnahme den Prozeß anhält.

Und irgendwie finde ich es nach wie vor eigenartig, daß die Kiste so schnell zu heiß wird.

[Yadgar]

Hi(gh)!

Abgesehen von JTHs Einwand, auf größer/gleich bzw. kleiner/gleich zu testen, befinden sich im /sys-Dateisystem noch weitere nützliche Dateien. Dort sind auch (irgendwo) die minimale, maximale und aktuelle CPU-Frequenz abgelegt. Statt deine Prozesse anzuhalten könntest du auch eine temperaurabhängige Frequenzanpassung bauen, die erstmal versucht, die Temperaturen durch runtertakten im Zaum zu halten und nur als letzte Notfallmaßnahme den Prozeß anhält.

Im laufenden Betrieb die Taktung verändern - das geht?!? Wie?

Und irgendwie finde ich es nach wie vor eigenartig, daß die Kiste so schnell zu heiß wird.

Enges stickiges supergedämmtes Wohnklo ohne Klimaanlage (die ich mir eh nicht leisten kann), U-förmig geschnitten, so dass man kaum lüften kann... Computer steht in der mit Regalen zugebauten rechten straßenseitigen Zimmerecke, direkt neben der Balkontür - aber die öffnet nach rechts, so dass auch bei geöffneter Tür keine kühlere Luft an den Computer kommt, nur bei Kippstellung. Und dann besteht ja auch noch die Möglichkeit, dass die Kühler-Haftcreme bröckelig geworden ist... ich müsste das mal vom Profi überprüfen lassen, mit meinen dreieinhalb linken Wurstfingerhänden gehe ich da nicht dran!

[Tintom]

Im laufenden Betrieb die Taktung verändern - das geht?!? Wie?

Guck mal in /sys/bus/cpu/devices/cpu*/cpufreq/
Bei deinem Prozessor könntest du auch im Journal / dmesg nach Meldungen des Kernelmoduls powernow schauen

[MSfree]

Im laufenden Betrieb die Taktung verändern - das geht?!? Wie?

Natürlich geht das. AMD hat die Cool-and-Quiet Technik mit dem Opteron eingeführt. Normalerweise kümmert sich der Kernel um die Frequenzanpassung, je nach Last wird die CPU im laufenden Betrieb hoch oder runter getaktet. Es gibt dafür verschiedene CPU-Governors, bei mir ist Powersafe von Haus aus geladen.

Mit

Code: Alles auswählen

find /sys | grep freq

solltest du das Verzeichnis finden, in dem die sogenannten "scaling"-Einträge stehen, bei mir sind das /sys/devices/system/cpu/cpu*/cpufreq (ein Verzeichnis pro CPU-Kern). Die Einträge scaling_min_freq und scaling_max_freq bestimmen den Bereich. scaling_max_freq könntest du bei zu hoher Temperatur runtersetzen.

Und dann besteht ja auch noch die Möglichkeit, dass die Kühler-Haftcreme bröckelig geworden ist.

Naja, die "bröckelige Wärmeleitpaste" ist eigentlich ein Mythos, der gerne unter Gamern verbreitet wird. Ich habe jedenfalls noch nie bröckelige Paste gesehen, auch nicht bei 20 Jahre alten Kisten.

Im Grunde ist das immer ein schlecht sitzender Kühler, der einseitig zu wenig Anpressdruck hat und sich dann ein Luftspalt zwischen CPU und Kühler bildet. Diese Pushpins sind besonders anfällig, die rutschen gene mal aus den Löchern im Mainboard raus. Bei mir sind die Kühler daher auch mit baumarktüblichen M3-Schrauben und Muttern befestigt, das hält ewig.