[gelöst] .timer soll alle x sekunden einen service/script ausführen

[joe2017]

Hallo zusammen,

ich habe ein Script geschrieben, welches alle x Sekunden ausgeführt werden soll. Hierzu habe ich einen Timer und einen Service erstellt welche dieses Script ausführen. Das funktioniert soweit alles bestens. Jedoch wird mein Script nicht alle x sekunden wie eingestellt ausgeführt. Vielleicht sieht jemand mein Fehler und gibt mir einen kleinen Tipp.

Timer:

Code: Alles auswählen

[unit]
Description=blablabla

[Timer]
OnBootSec=0min
OnUnitActiveSec=5s
Unit=hier steht der name meines Service.service

[Install]
WantedBy=timers.target

Eigentlich sollte der Service alle 5 Sec ausgeführt werden.

[TomL]

Der Fehler ist m.M.n. die Service-Unit an sich. Ich würde vor dem Hintergrund des sehr kurzen Zyklus das Script "einmalig" via Service-Unit starten und dann im Script innerhalb eines Endlos-Loops einen 5-Sekunden-Sleep eintragen. Die startende Service-Unit bekommt dann nur noch ein restart-allways-Statement und gut ists. Einen timer für so kurze Zyklen schätze ich fast als Design-Fehler ein.

[joe2017]

Hi TomL,

danke für deine schnelle Info. Das war auch mein erster Plan. Wenn es aber ein Problem mit dem Script gibt, oder dieses Beendet würd, wird es nicht weiter ausgeführt.
Mit dem Timer würde es immer wieder gestartet werden. Deshalb habe ich den größeren Aufwand gewählt.

[Lord_Carlos]

Was sagt systemctl status foo.timer? systemctl list-timers --all zeigt in an?
systemctl daemon-reload hast du nach dem erstellen des timers gemacht?
Timer hat du aktivert? systemctl enable foo.timer

[joe2017]

systemctl list-timers --all das zeigt meinen timer gar nicht an.
Aktiviert habe ich meinen Timer natürlich. Der Timer funktioniert ja auch. Jedoch nur nicht in der angegebenen Zeit.
Mein Timer liegt in folgendem Verzeichnis: /etc/systemd/user/
Hier liegt im übrigen auch mein Script.

[Lord_Carlos]

Mit script meinst du script? Oder Service?
Geht das service denn ueberhaupt?

Meine timers and services liegen hier: /etc/systemd/system

[JTH]

Ein paar Anmerkungen:

Die Zeile ManagedBy=timers.target in deinem Timer ist verkehrt, das sollte wahrscheinlich WantedBy= werden. (Oder bin ich da nicht mehr auf dem neuesten Stand?) Wenn du das verbesserst anschließend

Code: Alles auswählen

# systemctl --global daemon-reload
# systemctl --global enable X.timer

nicht vergessen.

Wenn der Timer per User läuft (da unter /etc/systemd/user) musst du systemctl jedes mal ein --user mitgeben, z.B.

Code: Alles auswählen

$ systemctl --user list-timers
$ systemctl --user status X.timer

Wenn du Timer im x-Sekunden-Takt ausführen willst, muss du die Genauigkeit des Timers erhöhen. Die ist per Default nur bei 1 min:

Code: Alles auswählen

[…]

[Timer]
AccuracySec=1

[…]

Die Zeile mit OnBootSec= kannst du dir vermutlich sparen. Da es ein User-Timer ist, läuft er sowieso erst, wenn sich ein Benutzer anmeldet.

[joe2017]

Oh Entschuldigung. Ja ich meinte natürlich service und timer

[joe2017]

Und noch einmal mein Fehler! Das kommt davon wenn man in gedanken ist und abschreibt anstatt zu kopieren. Natürlich steht hier "WantedBy=" Ich bessere das oben gleich mal aus!
Bei dem folgenden Befehl sehe ich jetzt den Service. Dieser wird immer noch alle 1 Minute ausgeführt.
systemctl list-timers --all --user

Trotz der Erweiterung

Code: Alles auswählen

OnCalendarSec=5s
AccuracySec=1s

Folgendes hat jetzt geholfen!

Code: Alles auswählen

systemctl --global daemon-reload

Vielen Dank!

[TomL]

Wenn es aber ein Problem mit dem Script gibt, oder dieses Beendet würd, wird es nicht weiter ausgeführt.

Nein, das stimmt so nicht... natürlich wird es bei einem Fehler (Absturz) erneut gestartet und wieder ausgeführt. Deswegen hatte ich auf das Statement "restart-always" oder alternativ "on-failure" hingewiesen. Siehe: https://www.freedesktop.org/software/sy ... rvice.html.

Mit dem 5-Sekunden-Timer erzeugst Du meiner Meinung nach auf jeden Fall eine unverhältnismäßige Systemlast für den Systemmanager, die permanent die CPU-Last und damit den Stromverbrauch hochhält. Ich halte das auf jeden Fall für einen Design-Fehler und würde das anders lösen. Mit dem 5-sec-Sleep-Statement im Script hättest Du diesen imho negativen Umstand nicht.

[joe2017]

Was würdest du mir vorschlagen? Ein Sleep im Script würde doch das selbe verursachen.

[TomL]

Was würdest du mir vorschlagen? Ein Sleep im Script würde doch das selbe verursachen.

Nein, überhaupt nicht.... der sleep ist hinsichtlich CPU völlig neutral. Damit wird aber der komplette Verwaltungs-Overhead für den System-Manager vermieden. Und sofern das Programm möglicherweise jedesmal auch noch von der Platte geladen wird, wird auch noch durchgängig die Platte am Spindown gehindert.... da weiss ich allerdings nicht, ob der Cache darauf noch Einfluss hat. Allerdings hätte ich keine Lust, das herauszufinden, sondern würde solche Effekte von vornherein durch eine andere Logik ausschließen.

[joe2017]

Mein Script prüft auch nur einen bestimmten Inhalt einer Datei. Wenn in dieser Datei nichts verändert wird, wird sonst auch nichts ausgeführt. Lediglich die Ausführung des Scripts wird durchgeführt.
Aber wenn du der Meinung bist, dass ich hier grundlegend etwas falsch denke, dann nehme ich deinen Rat sehr gerne an. Ich dachte einfach das ich es gleich richtig mache.

[TomL]

Mein Script prüft auch nur einen bestimmten Inhalt einer Datei.

Mir gings nicht um die Datei, sondern das Script wird ja im 5 Sekunden-Zyklus geladen, erzeugt eine Prozess-ID, der System-Manager richtet seine Überwachung ein, und nach Ende muss alles wieder aufgeräumt werden, um sofort wieder von vorne anzufangen.

Um die Datei auf Änderungen zu prüfen, würde ich auch einfach mal inotify-tools oder incron erwähnen, dann spart man sich die permanente Überwachung und nutzt einen Eventhandler. Letztlich ist es aber wieder so, dass man faktisch keinen Rat geben kann, weil wieder nicht bekannt ist, mit welchen Zutaten zu welchen Ereignissen welcher Kuchen für welche Gäste in welcher Größenordnung gebacken werden soll. Insofern können alle Ratschläge als Zufallstreffer passen oder eben nicht. Aber so ein Vorgehen ist m.M.n. Zeitverschwendung.

[joe2017]

Ja da stimme ich dir vollkommen zu. Die Anforderung habe ich hier nicht genau beschrieben, da ich nur nach einer Lösung zu einem Problem innerhalb meiner Routine gefragt habe.
Aber wahrscheinlich hast du Recht mit deiner Vermutung. Ich werde mir das Thema mal genauer anschauen und evtl nur mit einem Script arbeiten. Vielleicht ist das in diesem Fall auch ausreichend.

Vielen Dank auf jeden fall für deinen Gedankenanstoß. Ich lerne gerne immer weiter dazu.
Ich bin jetzt auch noch kein eingefleischter Debian User und lerne täglich dazu.

Nochmal ein großes Lob an alle User hier. Hier bekommt man immer nützliche Informationen welche mir bis jetzt immer weiterhelfen konnten.

[Lord_Carlos]

Mit dem 5-Sekunden-Timer erzeugst Du meiner Meinung nach auf jeden Fall eine unverhältnismäßige Systemlast für den Systemmanager, die permanent die CPU-Last und damit den Stromverbrauch hochhält.

Glaubst du ein 5 Sekunden .timer verursacht messbaren unterschied im Stromverbrauch und/oder load?

[TomL]

Glaubst du ein 5 Sekunden .timer verursacht messbaren unterschied im Stromverbrauch und/oder load?

Ich beziehe mich da nur auf meine eigenen Beobachtungen.... insofern kann ich da nicht von "nur glauben" sprechen. Ich habe einen 5-Minuten-Timer und konnte dabei mit htop konkret beobachten, wie die Last bei diesem Prozess mit Laden, Ausführen, Prozess-Verwaltungsoverhead, usw. nachweislich hochgeht. Und weil ich nicht wusste, welche Auswirkung das evtl. auch auf den Sleep der Platte hat, habe ich aus dem Grund und mit gleicher Motivation für diesen Job eine RAM-Disk angelegt, die regelmäßig auf meinen Web-Space gesichert wird, um selbst für diesen langen Zyklus (5 Min.) die Platte (gerade auch die ständig aufgeweckte und neu anlaufende Mechanik) trotzdem rausnehmen zu können. Bei einem so kurzen Zyklus von 5 Sekunden gibts ja faktisch gar keine Entspannungsphasen mehr, deshalb glaube ich also schon, dass solche Überlegungen relevant sind.

Bei einem 5-Sekunden-Zyklus halte ich allenfalls noch den Cache für eine reduzierende Einflussgröße... aber ich kann das nicht greifen, oder beeinflussen, oder erklären... insofern verlass ich mich da lieber nicht auf den Cache. Und soweit es den Stromverbrauch (nicht aktuell, sondern auf die Jahressumme bezogen) angeht, entscheide ich mich immer nach der Devise "jede Möglichkeit zur Minimierung des Verbrauchs wird beachtet"

[MSfree]

Bei einem so kurzen Zyklus von 5 Sekunden gibts ja faktisch gar keine Entspannungsphasen mehr, deshalb glaube ich also schon, dass solche Überlegungen relevant sind.

Ich halte 5 Sekunden Polling auch für eine unglückliche Idee. Wenn irgendwie möglich, sollte man auf Polling verzichten und versuchen, das ereignisgesteuert umzusetzen (was auch immer mit der Datei überwacht werden soll)

Trotzdem gibt es im Linuxkernel eine Möglichkeit, die Festplatte möglichst selten hochzufahren, das geht allerdings auf Kosten der Datensicherheit. Mit dem Kernelparameter /proc/sys/vm/laptop_mode kann man das System dazu bringen, die Platte nur dann hochzufahren, wenn die benötigen Daten nicht im Cache liegen. Bei einer kleinen Datei, die alle 5 Sekunden abgefragt wird, ist die Wahrscheinlichkeit, daß der Inhalt im Cache liegt, fast 100%. Die Datensicherheit ist bei Stromausfall allerdings gefährdet, weil der Cache möglichst selten auf die Platte geflusht wird.

Setzen des Laptopmodes:

Code: Alles auswählen

echo "1" > /proc/sys/vm/laptop_mode

Abschalten:

Code: Alles auswählen

echo "0" > /proc/sys/vm/laptop_mode

Oder

Code: Alles auswählen

sys.vm.laptop_mode = 1

in der Datei /etc/sysctl.conf permanent eintragen.

[TomL]

Ich habe aus Neugier mal ein bisschen gesucht und was interessantes gefunden:
https://www.computerbase.de/2018-08/cpu ... amd-intel/
Zitat:
"Intels aktuelle Definition der TDP
Intel definiert die TDP aktuell als „die durchschnittliche Leistungsaufnahme (in Watt), die der Prozessor beim Betrieb auf Basisfrequenz ableitet, wenn alle Kerne bei einer von Intel definierten, hochkomplexen Arbeitslast aktiv sind“.

Und wenn ich mir jetzt die TDP-Werte von Intel-CPUs anschaue, dann muss man doch zu dem Schluß kommen, dass hohe CPU-Aktivität aufs Jahr bezogen auch einen hohen Stromverbrauch verursacht:
https://de.wikipedia.org/wiki/Liste_der ... en#Desktop

BTW: häufig wird ja genau darauf auch als Nebeneffekt nach einem Cryptojacking hingewiesen.

...und versuchen, das ereignisgesteuert umzusetzen (was auch immer mit der Datei überwacht werden soll)

Das ist auch meine Meinung.

[MSfree]

Und wenn ich mir jetzt die TDP-Werte von Intel-CPUs anschaue, dann muss man doch zu dem Schluß kommen, dass hohe CPU-Aktivität aufs Jahr bezogen auch einen hohen Stromverbrauch verursacht:
https://de.wikipedia.org/wiki/Liste_der ... en#Desktop

Nicht wird so heiß gegessen, wie es gekocht wird

Ich habe alle meine Rechner bisher mit einem Wattmeter untersucht:
Core2-Quad Q9300 (lüfterlos), 95W TDP, Leerlauf 56W, maximale Auslastung 110W
i7-2600, 95W TDP (lüfterlos), Leerlauf 26W, maximale Auslastung 95W
i5-3450, 77W TDP (quasi lüfterlos), durchschnittlich 25W, maximal nicht gemessen
i3-7100, 51W TDP (quasi lüfterlos), Leerlauf 15W, maximale Last 50W

Jeweils ab Steckdose gemessen. Bei (optimistischen) 80% Netzteilwirkungsgrad und abzüglichen Leistungen von Festplatten, Mainboard, RAM etc. komme ich also nicht einmal in die Nähe der von Intel angegebenen TDP.

Ich schätze, daß der
Q9300 maximal 70W
i7-2600 maximal 60W
i3-7100 maximal 30W
verbrauchen. Die TDP-Werte werden vermutlich nur mit Burn-In Werkzeugen erreicht, die alle Rechenwerke und die Onboard-Graphik gleichzeitig maximal Auslasten können.

[TomL]

Nicht wird so heiß gegessen, wie es gekocht wird

Ja, das hatte ich auch so interpretiert... als einen Wert bei maximaler Auslastung. Aber nehmen wir mal Deine CPU

i7-2600, 95W TDP (lüfterlos), Leerlauf 26W, maximale Auslastung 95W

und projizieren das auf meine Anwendung: Meine CPU dümpelt außerhalb des 5-Min-Takts so zwischen 0,7% bis 3% CPU-Last vor sich hin... da laufen im Hintergrund 2 VMs. Im Moment meines 5-Minuten-Zyklus schnellt die CPU-Last allerdings auf 40-60% hoch, was aber wiederum nur 1 Sekunde dauert, wenn "ereignislos" die Grundlage war.

Und da stell ich nun die Frage, wie sich möglicherweise 0,7-3% von 95W im Vergleich zu 40-60% von 95W auf den Stromverbrauch auswirken, wenn das im 5-Sekunden-Takt das ganze Jahr über passiert. Ich betrachte das jetzt mangels Sachkenntnis mit Milchmädchen-Logik... und insofern weiss ich natürlich nicht, inwieweit ich das falsch interpretiere... ... aber irgendeinen Zusammenhang mit gemessener CPU-Last und Watt-Leistung und deswegen Einfluss auf Betriebskosten (und damit zwangläufig auch auf die Umwelt) muss es ja geben.

[MSfree]

und projizieren das auf meine Anwendung: Meine CPU dümpelt außerhalb des 5-Min-Takts so zwischen 0,7% bis 3% CPU-Last vor sich hin... da laufen im Hintergrund 2 VMs. Im Moment meines 5-Minuten-Zyklus schnellt die CPU-Last allerdings auf 40-60% hoch, was aber wiederum nur 1 Sekunde dauert, wenn "ereignislos" die Grundlage war.

Alle paar Sekunden einen 50%-Last für vielleicht 0.1s bringt den durchschnittlichen Stromverbrauch nicht siginifikant nach oben. Statt (meiner) 26W im Leerlauf, kommt man dann vielleicht auf 27-28W. Viel problematischer ist, wenn eine rotierenden Platte dann nie mehr abschaltet. Platten ziehen etwa 5-7W aus dem Netzteil, bzw. 7-10W aus der Steckdose.

10W Mehrverbrauch durch Platte und 5 Sekunden Polling kosten dann halt bei 24/7-Betrieb rund 26 Euro pro Jahr.

[TomL]

Alle paar Sekunden einen 50%-Last für vielleicht 0.1s bringt den durchschnittlichen Stromverbrauch nicht siginifikant nach oben.

Das ist natürlich jetzt eine optimistische Annahme, dass der Prozess nur 0.1 Sekunde dauert. Klar, das denke ich auch, dann wird das wirklich kaum den Stromverbrauch nach oben triggern.

Aus Neugier habe ich mir gerade mal nen Test-Script angelegt... und ja, ich weiss, nen Loop ist auch nicht der wahre Jakob... brauchst also gar nicht erst zu meckern ... ... also, ich war einfach nur mal Neugierig... ob sich das für Rückschlüsse eignet, weiss ich nicht... ich leite aber daraus ab, dass man dem Programm-Design durchaus mehr Beachtung schenken sollte. Der loop simuliert einfach nur mal einen kurzen Job (, mit der Genauigkeit eines Schätzeisens ... )

Meine CPU: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Das Script:

Code: Alles auswählen

#!/bin/bash

a=0
for (( c=0; c<=40000; c++ ))
do  
   a=$a+1
done

echo "Programm gestartet!" | systemd-cat -t "thlu:`basename $0`" -p info
exit 0

Bei dem Beispiel marschierte ein Kern mehr als die Hälfte des Timer-Zyklus-Zeitraums (subjektive Beobachtung) konstant auf 100%, dann noch mal kurz zurück auf 50%, dann wieder auf <1% Die Entspannung zwischen 2 Zyklen beträgt (wieder subjektive Beobachtung) ca. 1 Sekunde. Am Ende sah es so aus, als wäre annähernd 4/5 der Zyklus-Zeit CPU-Action angesagt. Ich denke schon, aufs gesamte Jahr betrachtet, würde man das merken. Jetzt ist natürlich klar, man wird davon nicht arm... aber an vielen Punkten im Haushalt eben auch bei solchen kleinen Verbraucher effektiv den Verbrauch reduziert, ergeben in Summe dann m.M.n. wieder einen deutlichen persönlichen Vorteil. Die Frage ist natürlich offen, was passiert überhaupt in so einem Prozess...?... wie lange braucht er dafür, wie hoch ist die CPU tatsächlich beansprucht? Ohne diese Angaben kann man eh nur Schätzungsszenarien entwerfen. Aber da genauer hinzuschauen lohnt sich allemal.

[MSfree]

... wie lange braucht er dafür,

Zumindest das kann man messen:

Code: Alles auswählen

time NameDesScriptes

liefert die CPU-Zeit für die Ausführung. Das ist auf jeden Fall zuverlässiger als (h)top, xosview und Konsorten.