update.sh: Auf die Regelschleife warten statt auf gut Glück zu schlafen #2361
Conversation
yankee42
force-pushed
the
wait-regel-instead-sleep
branch
from
cce8775 to
886b254
Compare
|
Ich versteht die funktion nicht. Regelschleife ist auch eingentlich falsch. |
|
Ok, Groschen gefallen. |
|
Die 15 Sekunden in Update haben schon ihren Sinn. Wenn du die Zeit sparen willst.,
|
|
Aber..... |
Nein. Sollte zumindest nicht sein. Es sollte nur so lange laufen wie die regel.sh braucht. Wenn du sagst, dass die regel.sh bei dir ca. 5 Sekunden läuft würde das bedeuten, dass wenn du die Zeile zur ersten Sekunde von vollen 10 Sekunden startest (also zum Beispiel um 12:37:20), dann würde es zu einem sleep von 5 Sekunden kommen. Wenn du die Zeile um 12:37:23 startest, dann nur ein Sleep von 2 Sekunden (vorrausgesetzt die regel.sh ist um 12:37:25 fertig).
Richtig. Wenn du die Zeile zwischen 12:37:25 und 12:37:30 startest, dann gibt es kein sleep.
Nein. Die update.sh setzt erst das Lines 9 to 10 in 15833c7 Dann erst kommt das Line 60 in 15833c7 In der Lines 32 to 37 in 3ff5750 Es mag in seltenen Fällen vorkommen, dass die regel.sh schon an dem Flag-Check vorbei ist und daher das "Stop" noch verarbeitet, das dürfte aber eher die Ausnahme sein und schon garnicht die Intention. In den meisten Fällen wird das setzen vom Lademodus keinen Effekt auf das haben, was vor dem Update passiert. |
|
Aber wenn du gerade mal dran bist.... Cron5 und Cronnighly sowie andere update.sh instancen muss du auch noch testet........ |
|
Berücksichtige.... |
Gute Idee. Baue ich noch ein. |
|
Das sollte wohl besser dahinter erst gesetzt werden PS: |
|
Ich persönlich habe es schon häufiger geschaft ein runde des Cron5min auszulassen. |
yankee42
force-pushed
the
wait-regel-instead-sleep
branch
2 times, most recently
from
0cf35ad to
d1a2c0a
Compare
Ist jetzt drin.
Du meinst ein richtiger Systemneustart? Es hätte immerhin den Charme, dass es einen Fall weniger gäbe. Also es gäbe nicht mehr den Fall "atreboot nur so" und "atreboot aus Systemneustart". Ein Testfall weniger. Dafür dauert es aber wieder etwas länger. Und bis jetzt läuft es ja gut. Ist aber nicht im Scope von diesem PR.
Nach 15 Sekunden ist der timeout. Dann bist du wohl da rein gelaufen. Vielleicht weil du wieder irgendwelche Sachen anders hast auf deinem System, so dass da ein anderes Script matcht oder so? Was gibt dir denn nur das |
|
Zu aller erst muss mal der $ am ende weg, also nocmal das ganze aktualisierte Script x.sh und seine Wirkung |
Nein. Genau nicht: Es soll in dem Beispiel nur auf den 8496 matchen, aber nicht auf die 3315 und die 3316. Das |
|
Ok, aber mit "$" hab ich trotz minutenlangem probieren keinen "Treffer" also immer (~0) PS: |
Was gibt denn folgendes bei dir aus?: sleep $(( 11 - $( date +%S | cut -c2 ) )); ps x | grep regel.shUnter der Annahme, dass du den Regelintervall auf "schnell" stehen hast, müsstest du damit auf jeden Fall die laufende Regelschleife erwischen. |
|
Hm.... aber Regel.sh läuft definitve (tail -f ramdisk/openWB.log läuft mit ) |
|
Auf der orignal-openWB (hostname openwb statt pi67) Hier läuft regel.sh 7-8 Sekunden (1.9.244) und da ist die warscheinlichkeit regel.sh beim arbeiten anzutreffen deutlich höher. |
|
Nimm 12 statt 11 dann klappt die Zeile zuverlässiger |
OK, prima. Mir gingen schon die Ideen aus ;-). Dann müsste auch |
|
Leider nicht sollange das ps nur mit x statt alx aufgerufen wird. also erst ....wobei verstehen tu ich den effect nicht. |
|
Ich versteh's nicht. Hier 8 mal gestartet 4* mit "alx" 4* mit "x" |
An dem |
|
Es liegt am User. also root mit "x" kommte das regel.sh von pi nicht mit raus. also mit eingestreutem sudo -u pi Oh man, was man sich mit dem "nicht allles als root machen" so alles einfängt.... |
Oh man, was mit sich alles damit einfängt, dass du alles als root machst. |
|
Alte gewohnheit :-) |
|
Die Quintessenze unseres Dialoges sollte aber sein. Das Script MUSS als pi laufen und sollte die Arbeit verweigern wenn es von solchen Trotteln wie ich mal als root aufgerufen wird. oder das Script wird "root"-Fest gemacht (mit sudo's und ps -alx etc) |
yankee42
force-pushed
the
wait-regel-instead-sleep
branch
from
d1a2c0a to
dd84c69
Compare
yankee42
force-pushed
the
wait-regel-instead-sleep
branch
from
dd84c69 to
4292c29
Compare
…rder to (possibly) speed up the script
yankee42
force-pushed
the
wait-regel-instead-sleep
branch
from
4292c29 to
bae9ef7
Compare
|
Nochmal auf den aktuellen master rebased. Das Thema ist immernoch aktuell. Ich habe die Konversation nochmal reviewed, aber nichts gefunden was noch offen wäre, was einem merge entgegenstehen würde. Einziger "offener" Kommentar wäre:
Das erscheint mir zwar durchaus sinnvoll, wäre aber eine Änderung am Verhalten des Scripts. Um den Scope dieses PR übersichtlich zu halten würde ich das als "follow-up" später sehen. |
z.B. so sicherstellen: |
4 participants
In der
update.shgibt es einsleep 15. Warum? Es ist ein Faktor der Updates langsamer macht. Gerade wenn man Änderungen "eben schnell" testen will ist das nervig, dass das Update so lange dauert.Das ganze kam aus commit 90fd667, in dem die commit-message "schalte lademodus auf stop bei update start" steht. Damals wurde ein Befehl eingeführt, der den Lademodus auf stop stellt und dann 15 Sekunden wartet. Ich nehme schwer an um darauf zu warten, dass der neue Lademodus aktiv wird. Das hat sich wohl durch das
updateinprogress-Flag erledigt. Der Lademodus wird zwar noch auf "stop" gestellt, die Regelschleife macht damit aber ohnehin nichts mehr, denn sie bricht wegen demupdateinprogress-Flag sofort ab.Es erscheint mir aber trotzdem schlau ein Update nicht in eine laufende Regelschleife reinzuwerfen. Wenn dem laufenden Programm der Quelltext ausgetauscht wird und potentiell auch Dateien überschrieben werden mit denen die Regelschleife arbeitet oder deren Berechtigungen geändert werden könnte das Fehler nach sich ziehen.
Dieser PR ändert das Verhalten so, dass nur gewartet wird, wenn die Regelschleife gerade läuft und dann auch nur so lange bis die Regelschleife endet. Maximal jedoch weiterhin 15 Sekunden, damit eine hängende Regelschleife nicht den ganzen Prozess lahmlegt. Man könnte überlegen ob 15 Sekunden ausreichen, da manche Leute (zum Beispiel die Geschichte mit den Huawei-WR) sehr langsame Regelschleifen haben und die 15 Sekunden dann vielleicht nicht ausreichen. Andererseits haben die 15 Sekunden bis jetzt scheinbar ihren Dienst getan...