Fried-rich
Anmeldungsdatum: 2. Mai 2013
Beiträge: 1093
|
Hallo, ich habe mir über die Jahre ein paar Scripte erstellt die ich in Thunar mit Benutzerdefinierten Aktionen starte und die dann länger dauerte Prozesse als Batchliste ausführen. Das ganze wird in einem Terminalfenster angezeigt. Da ist auch das hier drin: lockfile -r 0 /tmp/audio-encoding.lock || exit 1
function lock-remove {
rm -f /tmp/audio-encoding.lock
rm -f /tmp/audio-encoding-*
exit
}
trap lock-remove EXIT Die *.lock-Datei bewirkt, dass die Scripte kein zweites mal gestartet werden. Die "audio-encoding-*" sind die Dateien der Batch-Liste die nacheinander abgearbeitet werden. Anstelle des * kommt ein Datumscode in Millisekunden damit sie in der gleichen Reihenfolge abgearbeitet werden in der ich sie hinzugefügt habe. Wenn ich das Terminalfenster manuell schließe wird die Funktion "lock-remove" ausgeführt und eigentlich sollte dann die "audio-encoding.lock" und alle Scripte gelöscht werden. Die Lock-Datei wird gelöscht, die Scripte nicht. Unter 18.04 lief das problemlos. Irgendwie kann ich aus einem Script heraus nichts mehr mit * löschen. Manuell im Terinal geht das, nur aus dem Script heraus nicht. Es scheint auch andere Befehle zu betreffen. Hab einfach mal statt rm versucht die Datei mit cp audio-encoding-* /home/friedrich zu kopieren. Ging auch nicht. Wurde da etwas geändert? Friedrich
|
Doc_Symbiosis
Anmeldungsdatum: 11. Oktober 2006
Beiträge: 4391
Wohnort: Göttingen
|
Nur um sicherzugehen, solltest Du vielleicht eine Shebang in dein Skript Schreiben, also folgende in die erste Zeile:
#!/bin/bash Und wie rufst Du das Skript auf? Einfach im Terminal? Welche Shell ist da denn aktiv?
echo $SHELL
|
Fried-rich
(Themenstarter)
Anmeldungsdatum: 2. Mai 2013
Beiträge: 1093
|
Shebang ist drin. Das script wird gestartet mit 'lxterminal -e /Pfad/zum/script'. Hab es jetzt mit dem -exec rm {} des find Kommandos gemacht. Scheint zu gehen, wenn auch umständlich.
|
Doc_Symbiosis
Anmeldungsdatum: 11. Oktober 2006
Beiträge: 4391
Wohnort: Göttingen
|
Statt -exec rm {} sollte man lieber -delete verwenden.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Ich mache das einfacher: ich sperre einfach die Skriptdatei. 1
2
3
4
5
6
7
8
9
10
11
12 | #!/bin/sh
# concurrent code
{
flock -n 9 || exit 1
# exclusive code
} 9<"$0"
# concurrent code
|
|
Fried-rich
(Themenstarter)
Anmeldungsdatum: 2. Mai 2013
Beiträge: 1093
|
Mag alles sein, ist aber komisch, dass man aus einem Skript kein 'rm name*' mehr aufrufen kann. Die Shell ist übrigens die Bash.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Fried-rich schrieb: Mag alles sein, ist aber komisch, dass man aus einem Skript kein 'rm name*' mehr aufrufen kann.
Schau mal, ob Du irgendwo set -f stehen hast. In der Funktion sollte kein exit stehen, denn die Shell terminiert ja sowieso. Aber eigentlich brauchst Du auch keine Funktion: das geht einfach so: | trap 'rm -f /tmp/audio-encoding.lock /tmp/audio-encoding-*' 0
|
Die Lockdatei ständig anzulegen und zu löschen erhöht das Risiko von Race-Conditions. Der Ansatz mit flock ist moderner und robuster.
|
Fried-rich
(Themenstarter)
Anmeldungsdatum: 2. Mai 2013
Beiträge: 1093
|
Nein, sowas hab ich da nicht drin stehen.
Ich mache das einfacher: ich sperre einfach die Skriptdatei
Das heißt das Script wir kein zweites mal ausgeführt. Das geht ja aber bei mir nicht. Womöglich ist mein Ansatz auch umständlich. Das Script macht mehrere Sachen: es legt in /tmp ausführbare Dateien an, eine für jede Input-Datei es erstellt die Lock-Datei es führt die unter Punkt 1 erstellten Dateien in /tmp aus wenn keine mehr da sind wird die Lock-Datei gelöscht
Wenn gerade Punkt 3 läuft und es mir einfällt noch eine Datei in gleicher Weise bearbeiten zu müssen muss das Script ja dennoch ausgeführt werden, es ende aber bei Punkt 2. In /tmp ist nun eine Datei mehr die - wenn sie an der Reihe ist - abgearbeitet wird.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Fried-rich schrieb:
Ich mache das einfacher: ich sperre einfach die Skriptdatei
Das heißt das Script wir kein zweites mal ausgeführt.
Ja, aber wolltest Du das nicht? Das ist doch genau die Logik, die sich durch Deine erste Zeile ergibt: | lockfile -r 0 /tmp/audio-encoding.lock || exit 1
|
Es wird versucht, die Datei anzulegen. Wenn das nicht klappt terminiert das Skript. Das ist genau das, was ich mit dem flock mache.
Das geht ja aber bei mir nicht. Womöglich ist mein Ansatz auch umständlich. Das Script macht mehrere Sachen: es legt in /tmp ausführbare Dateien an, eine für jede Input-Datei es erstellt die Lock-Datei es führt die unter Punkt 1 erstellten Dateien in /tmp aus wenn keine mehr da sind wird die Lock-Datei gelöscht
Wenn gerade Punkt 3 läuft und es mir einfällt noch eine Datei in gleicher Weise bearbeiten zu müssen muss das Script ja dennoch ausgeführt werden, es ende aber bei Punkt 2. In /tmp ist nun eine Datei mehr die - wenn sie an der Reihe ist - abgearbeitet wird.
Also, es geht Dir im Kern darum, dass für alle Input-Dateien, die - so nehme ich mal an - als Kommandozeilenargumente übergeben werden, eine korrespondierende Datei ausgeführt wird. Dann macht man das halt so, dass die weiteren Aufrufe des Skriptes blockiert werden und erst weiter laufen, wenn das Lock freigegeben wurde. Der Code dafür sähe dann so aus: 1
2
3
4
5
6
7
8
9
10
11
12 | #!/bin/sh
# concurrent code
{
flock 9
# exclusive code
} 9<"$0"
# concurrent code
|
Wenn ich darüber nachdenke, frage ich mich allerdings, warum Du überhaupt die Locks brauchst bzw. die Ausführung serialisieren willst. Was genau macht denn das ganze? Andere mögliche Lösungen wären denkbar mit inotifywatch oder eine Named Pipe. Hängt davon ab, was Du da eigentlich baust. Beschreib mal abstrakt in Worten (nicht Code!), was das ganze machen soll.
|
Fried-rich
(Themenstarter)
Anmeldungsdatum: 2. Mai 2013
Beiträge: 1093
|
Ich bin mir nicht sicher ob wir das gleiche meinen. Es geht hier um Video- und Audio-Encoding oder andere Prozesse die besser nicht parallel laufen. Ich habe in Thunar Custom Actions angelegt, z. B. um ein Audioformat umzuwandeln. Diese Action startet ein Script, das folgendes tut es wird in /tmp für jede Input-Datei ein Script angelegt in dem die Zeile für den Encoding-Vorgang dieser einen Datei steckt; habe ich also 5 Dateien in Thunar ausgewählt, habe ich danach 5 Scripte in /tmp die Lockdatei wird angelegt die Funktion 'lock-remove' wird erstellt es wird eine Endlosschleife gestartet die nacheinander alle Scripte die mit dem entsprechenden Namen ausführen die Lock-Datei wird wieder gelösscht
Wieso das ganze: Früher habe ich über die Custom Action ein Script mit einer For-Schleife gestartet, das hat das gleiche gemacht, aber nur für die Datei die ich beim allerersten Aufruf ausgewählt hatte. Habe ich die Action erneut gestartet liefen diese 2. Vorgänge parallel ab. So habe ich eine echte Batch-Liste. Ich kann während der Vorgang läuft weitere Encoding dazu packen und die hinten angereiht werden. Die Sortierung erfolgt über einen Datumszusatz (in Millisekunden). Wenn ich beim ersten Aufruf der Action 5 Dateien gestartet habe und während das Encoding der 1. läuft weitere 2 hinzufüge, arbeitet die Endlosschleife in Summe 7 Scripte ab. Meine ersten Versuche habe ich noch mit einer Textdatei in /tmp gemacht, aus der wieder eine Schleife immer die 1. Zeile genommen, abgearbeitet, gelöscht und dann die nächste Zeile (die dadurch an die 1. Stelle gerückt ist) abarbeitet. Auch hier konnte ich noch Vorgänge hinten anstellen. Teilweise stecken in den Scripten aber mehr als nur die reine Aufruf zur Konvertierung, z. B. gebe ich den Dateien während die gerade konvertiert werden einen Zusatz um genau das kenntlich zu machen und lasse die dann umbenennen wenn sie fertig sind. Das geht zwar grds. auch als Einzeiler, ist aber umständlicher. Die oben genannte Funktion 'lock-remove' hat lediglich die Funktion alles was noch nicht fertig abgearbeitet wurde zu löschen, wenn ich den Vorgang abbreche - also das Terminalfenster schließe. Dann wird die Lock-Datei und alle noch existierenden Scripte gelöscht. Glaube früher zu Zeilen von Windows XP gab es mal ein Tool das einem genau diese Funktion geboten hat. Da konnte man Kommandozeilen hin verschieben die abgearbeitet wurden. Man konnte sie während alles lief verschieben (Reihenfolge ändern) und gruppieren (also Prozesse definieren die parallel zu anderen laufen dürfen und solche die das nicht dürfen). Galube für Linux hab ich eines gefunden, das aber schon vor ewigen Zeilen eingestellt wurde.
|
Fried-rich
(Themenstarter)
Anmeldungsdatum: 2. Mai 2013
Beiträge: 1093
|
Um auf das flock zurück zu kommen. Das lock steckt ja in dem Script, das durch die Custom Action gestartet wird. De lock verhindert nicht den kompletten Start des Scriptes, es verhindert, dass die Endlosschleife beginnt die Scripte in /tmp auszuführen - weil das ja schon läuft. Es bricht also das Script zu einem bestimmten Zeitpunkt ab.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Fried-rich schrieb: Ich bin mir nicht sicher ob wir das gleiche meinen.
Deshalb solltest Du ja beschreiben, was Du eigentlich erreichen willst.
Es geht hier um Video- und Audio-Encoding oder andere Prozesse die besser nicht parallel laufen.
Du willst also die Bearbeitung von Dateien so steuern, dass keine zwei parallelen Abarbeitungen um die CPU konkurrieren.
Ich habe in Thunar Custom Actions angelegt, z. B. um ein Audioformat umzuwandeln. Diese Action startet ein Script, das folgendes tut
Wenn Dein Skript ein Skript schreiben kann, das die Aufgabe ausführt, dann kann es sie doch auch direkt selber ausführen. Der einzige Grund, den ich mir vorstellen kann, ist, die Bearbeitung wieder aufzunehmen, wenn irgendetwas schief gehen sollte.
Die oben genannte Funktion 'lock-remove' hat lediglich die Funktion alles was noch nicht fertig abgearbeitet wurde zu löschen, wenn ich den Vorgang abbreche - also das Terminalfenster schließe. Dann wird die Lock-Datei und alle noch existierenden Scripte gelöscht.
OK, wenn Du den Inhalt Deiner Warteschlange sowieso verlieren willst, sobald Du abbrichst, dann gibt es erst recht keinen Grund dafür, die Konvertierungen in separate Skripte auszulagern. Fried-rich schrieb: Um auf das flock zurück zu kommen. Das lock steckt ja in dem Script, das durch die Custom Action gestartet wird. De lock verhindert nicht den kompletten Start des Scriptes, es verhindert, dass die Endlosschleife beginnt die Scripte in /tmp auszuführen - weil das ja schon läuft. Es bricht also das Script zu einem bestimmten Zeitpunkt ab.
Ja logisch. Ist mir klar. Nimm einfach die Lösung mit flock , die ich zuletzt beschrieben habe und lass die externen Skriptdateien weg - die machen die Sache nur unnötig kompliziert.
|
Fried-rich
(Themenstarter)
Anmeldungsdatum: 2. Mai 2013
Beiträge: 1093
|
rklm schrieb: Wenn Dein Skript ein Skript schreiben kann, das die Aufgabe ausführt, dann kann es sie doch auch direkt selber ausführen.
Nein. Denn dann werden nur die Dateien nacheinander abgearbeitet die ich in diesem einen Schritt für die Konvertierung ausgewählt habe. Gehe ich in einen anderen Ordner und mache das gleiche wird dieser Prozess parallel ausgeführt. Das ist im Grunde wie jedes Konvertierungtools, egal ob Audio oder Video. Du wirfst 5 Dateien in die Batchlist und startest diese. Er beginnt mit der ersten Datei. Während das läuft wirst du nochmal 5 rein, dann beginnt die Bathclist ja nicht mit diesen nachträglich hinzugefügten Dateien, sondern reiht sie ein. Wenn die ersten 5 durch sind, macht er mit den zweiten 5 weiter. Das mache ich hier auch. Könnte man vielleicht auch anders lösen als ich. rklm schrieb: OK, wenn Du den Inhalt Deiner Warteschlange sowieso verlieren willst, sobald Du abbrichst, dann gibt es erst recht keinen Grund dafür, die Konvertierungen in separate Skripte auszulagern.
Von 'wollen' kann keine Rede sein. Normal soll das schon alles konvertiert werden. Nur wenn ich den Vorgang abbreche sollen die Scripte (die ja nicht mehr ausgeführt werden sollen) und die Lock-Datei logischerweise gelöscht werden.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12822
|
Fried-rich schrieb: rklm schrieb: Wenn Dein Skript ein Skript schreiben kann, das die Aufgabe ausführt, dann kann es sie doch auch direkt selber ausführen.
Nein. Denn dann werden nur die Dateien nacheinander abgearbeitet die ich in diesem einen Schritt für die Konvertierung ausgewählt habe. Gehe ich in einen anderen Ordner und mache das gleiche wird dieser Prozess parallel ausgeführt.
Um das zu verhindern ist ja der flock da. Aber das hat nichts damit zu tun, ob Du die Aufgaben in dem einen oder den anderen Skripten ausführst.
Das ist im Grunde wie jedes Konvertierungtools, egal ob Audio oder Video. Du wirfst 5 Dateien in die Batchlist und startest diese. Er beginnt mit der ersten Datei. Während das läuft wirst du nochmal 5 rein, dann beginnt die Bathclist ja nicht mit diesen nachträglich hinzugefügten Dateien, sondern reiht sie ein. Wenn die ersten 5 durch sind, macht er mit den zweiten 5 weiter. Das mache ich hier auch. Könnte man vielleicht auch anders lösen als ich.
Ja, ich wiederhole mich ungern, aber genau dafür ist der flock da. Ich habe den Eindruck, Du hast Dich zu sehr auf Deine Lösung eingeschossen, als dass Du Dich mit anderen beschäftigen möchtest. Ist OK, muss man nur wissen.
rklm schrieb: OK, wenn Du den Inhalt Deiner Warteschlange sowieso verlieren willst, sobald Du abbrichst, dann gibt es erst recht keinen Grund dafür, die Konvertierungen in separate Skripte auszulagern.
Von 'wollen' kann keine Rede sein. Normal soll das schon alles konvertiert werden. Nur wenn ich den Vorgang abbreche sollen die Scripte (die ja nicht mehr ausgeführt werden sollen) und die Lock-Datei logischerweise gelöscht werden.
Aber das entspricht der Logik, dass Du alle Aufträge vergisst. Dann gibt es erst recht keinen Grund dafür, die Konvertierungsaufgaben in separate Skripte zu schreiben. Das macht es nur unnötig kompliziert und Du hast die zusätzliche Aufgabe, die Aufträge verlässlich zu löschen, was Du nicht machen musst, wenn Du die erst gar nicht anlegst.
|