Umgang und Probleme mit Shell Skripten

[henning-gerhardt]

Der aktuelle Ist-Stand ist wie folgt:

Im Workflow der Anwendung kann pro Workflow-Aufgabe ein Skript definiert werden, welches entweder durch manuelle Betätigung oder automatisch ausgeführt wird. Dabei gibt der Exit Status / Beendigungsstatus des aufgerufenen Skriptes an, ob diese Ausführung erfolgreich (Exit Status mit dem Wert 0) war oder nicht (Exit Status mit dem Wert 1).

Ggf. werden noch die Ausgaben des Skript Ausführung dem Benutzer angezeigt (im Fall der manuellen Ausführung) oder werden unterdrückt (im Fall der automatischen Ausführung). Wurde das Skript manuell gestartet / ausgeführt, dann wird bei der erfolgreichen Ausführungen die Standard-Ausgabe (stdout / Konsolen-Kanal 1) dem Benutzer präsentiert, bei einer erfolglosen Ausführung hingegen die Fehlerkonsole (stderr / Konsolen-Kanal 2).

Bei der manuellen Ausführung eines Skriptes muss der auszuführende Benutzer so lange warten bis sich das Skript beendet.

Wird ein Skript automatisch ausgeführt und ist der Beendigungsstatus erfolgreich, dann wird die damit verbundene Aufgabe automatisch geschlossen. Ist hingegen der Beendigungsstatus nicht erfolgreich, wird die Aufgabe vom Status "in Bearbeitung" auf "offen" gesetzt und die Aufgabe muss auf anderen Weg abgeschlossen werden.

Es dadurch viel Verbesserungspotential. Siehe auch #6449 und #6460 aber noch mögliche weitere:

• Da der Beendigungsstatus auf 2 Werte festgelegt ist, gibt es hier das Problem, dass automatische Aufgaben, die ein Skript starten aber durch bspw. ActiveMQ später geschlossen werden, weiterhin in dem Bearbeitungsstatus "offen" bleiben, obwohl die Bearbeitung asynchron weiter läuft. D.h. das aufrufende Skript startet die extern lang laufende Bearbeitung und beendet sich aktuell mit dem Beendigungsstatus 1, damit die Aufgabe selbst nicht abgeschlossen wird da ansonsten spätere Aufgaben Workflow auf "offen" gesetzt werden. Daher wäre es für dieses Szenario sehr gut, wenn es mindestens einen weiteren definierten Status gäbe, der anzeigt, dass eine Skript-Ausführung erfolgreich sich beendet hat, aber die Aufgabe aus der das Skript aufgerufen wurde, offen bzw. in Bearbeitung bleibt und durch einen anderen Mechanismus (bspw. ActiveMQ) abgeschlossen wird.

• Man kann aktuell im Workflow-Editor noch im Workflow selbst (für bestehende Aufgaben) nicht definieren, dass eine Skript-Ausführung asynchron erfolgen soll. D.h. bei jeder aktuellen Ausführung eines Skriptes muss entweder der Benutzer oder die Anwendung so lange warten bis das Skript zu einem Ende gekommen ist. Bei einer asynchronen Ausführung würde die Ausführung selbst bspw. über den internen Taskmanager durchgeführt werden. Nach Beendigung der Ausführung wird entweder der Benutzer, der das Skript manuell gestartet hat oder Person X bei automatischen Aufgaben über die Ausführung informiert. Dies ist bspw. in Add notification menu #6460 schon mit angedacht. Wobei mir die Speicherung / Vorhaltung der Nachrichten nicht ganz klar ist.

• Bei der Ausgabe einer Skript-Ausführung (unter Linux/Unix) stehen einen mindestens 2 Ausgabe-Kanäle zur Verfügung: stdout und stderr. Der erstere ist eher für die allgemeinen Ausgaben bestimmt und der letztere eher für Fehlermeldungen. Theoretisch stehen dem Skript / Programm beliebig viele Ausgabekanäle zur Verfügung, aber die Unterstützung weiterer kann später erfolgen. In der aktuellen Implementierung (Stand 11.03.2025) werden diese jedoch in der Reihenfolge so vermischt, dass zuerst alle Ausgaben von stdout kommen und danach die Meldungen von stderr. Bei einer Ausführung eines Skriptes ist aber nicht sichergestellt, dass nur am Ende die Fehlermeldungen von stderr kommen. Je nach Skript können die Fehlermeldungen auch schon eher ausgegeben werden. Es wäre besser, die Meldungen in der Reihenfolge des Erstellung dem Benutzer zu präsentieren. Gerade im Fehlerfall ist dies sehr wichtig. Fix script output #6450 adressiert das gemeldete Problem von Display output of non automatic script tasks to the assigned user #6449, jedoch ist die Reihenfolge der Meldungen ein separat zu lösendes Problem.

Gibt es noch weitere Verbesserungsideen oder Nutzungsprobleme im Kontext der Skript-Ausführung, die jetzt hier nicht adressiert sind? Wenn ja gerne ergänzen.

In einer jeweils separaten Diskussion sollte dann über die einzelnen Probleme Lösungen diskutiert werden bevor diese ggf. auch im Rahmen eines zukünftigen Entwicklungsfond oder durch Beauftragung oder selbständige Arbeiten gelöst werden.

Ich erwähne einmal @oliver-stoehr , @solth , @BartChris und @lutzhelm da die Personen in diesbezüglichen Diskussionen / Vorschlägen aktuell mit der Thematik vertraut sind aber auch jeder andere ist gern zum Beitragen hier eingeladen.

[oliver-stoehr]

Man kann aktuell im Workflow-Editor noch im Workflow selbst (für bestehende Aufgaben) nicht definieren, dass eine Skript-Ausführung asynchron erfolgen soll. D.h. bei jeder aktuellen Ausführung eines Skriptes muss entweder der Benutzer oder die Anwendung so lange warten bis das Skript zu einem Ende gekommen ist. Bei einer asynchronen Ausführung würde die Ausführung selbst bspw. über den internen Taskmanager durchgeführt werden. Nach Beendigung der Ausführung wird entweder der Benutzer, der das Skript manuell gestartet hat oder Person X bei automatischen Aufgaben über die Ausführung informiert. Dies ist bspw. in #6460 schon mit angedacht. Wobei mir die Speicherung / Vorhaltung der Nachrichten nicht ganz klar ist.

Eine weitere Möglichkeit, die Darstellung der Ergebnisse zu verbessern:
So wie die Ergebnisse für #6460 in der Datenbank oder auf ähnlichem Wege gespeichert werden müssten, um längerfristig angezeigt werden zu können, könnten man so eine Speicherung auch unabhängig von dem Vorschlag nutzen, um die Daten in oder unterhalb des Taskmanagers für einen längeren Zeitraum anzuzeigen. So könnte man unterhalb des "aktuellen" Taskmanagers eine Liste mit "kürzlich abgeschlossenen Einträgen" anzeigen. Diese könnten beispielsweise nur angezeigt werden, ohne irgendwelche Interaktionsmöglichkeiten. Die Einträge könnten automatisiert nach einem konfigurierbaren Zeitraum (z.B. 7 Tage) gelöscht werden.

[BartChris]

Nachdem ich ein wenig über das Thema nachgedacht habe, hätte ich ein paar Bemerkungen und gründsätzliche Fragen.

• Shell-Skript-Ausführung und Kitodo-interne Prozesse (z.B. Anlage von Zeitungsvorgängen oder EAD-Vorgängen bei denen es auch zu Problemen kommen kann - s. u.a. Taskmanager: rethink implementation #4137 ) sind evtl. unterschiedlich zu handhaben, da Skripte in einem externen Prozess laufen über den man weniger Kontrollmöglichkeiten hat. Shell-Skripte sind aus der JVM heraus praktisch nicht zu kontrollieren und "Black Boxes".

• Daher stellt sich die Frage, wie ein asynchroner Shell-Skript-Aufruf am besten zu handhaben ist. Eine Option wäre, sie auch über den internen Taskmanager abzubilden, eine andere wäre eine Nutzung von ActiveMQ (das vereinzelt zumindest bei der Rückmeldung in Skript-Aufgaben genutzt wird)

• Es gibt bereits jetzt in einzelnen Häusern "manuell" definierte asynchrone Tasks, wie z.B. die OCR, die über den Umweg von irreführenden Status Codes (1 = "offen") und ActiveMQ-Rückmeldungen realisiert werden.

• Es scheint mir Ausführungsszenarien zu geben, wie z.B. eine extrem lang laufende OCR oder die parallele Ausführung von sehr vielen Skript-Schritten, für die mir der Kitodo-Taskmanager nur bedingt geeignet scheint. (siehe als Beispiel die parallele Ausführung von automatischen Skript-Aufgaben in Szenarien mit paralleler Hochsetzung des Vorgangsstatus: Poor performance while raising/lowering task steps for many processes #6177)

Daher stellt sich mir die Frage, ob Kitodo nicht beides unterstützen müsste: a) Eine asynchrone Ausführung von Kommandozeilenskripten über den Task-Manager, um eine asynchrone Abwicklung von Skript-Schritten direkt in Kitodo zu ermöglichen und b) Eine Funktion zur Anlage von Jobs für asynchrone Aufgaben in Active MQ, die dann von einem externen Mechanismus abgearbeitet und über die bekannten Mechanismen in Kitodo abgeschlossen werden.

Die aktuelle Umsetzung wirklicher asynchroner Skripte über einen Workaround (Rückgabe-Wert 1 um die Aufgabe offen zu halten), sollte man daher im Idealfall um die Möglichkeit ergänzen in Kitodo (zumindest als Option) Jobs direkt in ActiveMQ abzulegen, und ActiveMQ damit noch besser in die Infrastruktur zu integrieren. Daneben sollte man kritisch evaluieren, inwiefern eine asynchrone Prozessierung von sehr vielen oder sehr lange laufenden Kommando-Zeilen-Prozessen im Rahmen der Kitodo-TaskManager-Steuerung überhaupt möglich ist. Oder ob man dann für die Abarbeitung sehr vieler bzw. lang laufender serieller Tasks nicht die Einbindung von Job Queues erleichtern sollte.
Natürlich benötigt man für Abarbeitung der ActiveMQ-Jobs dann externe Software-Komponenten. Da ActiveMQ aber bereits jetzt (optionaler) Teil der Infrastruktur ist, könnte man überlegen, zumindest auch die Anlage von Jobs in ActiveMQ zu einem (optionalen) Feature der Kitodo-Workflow-Ausführung zu machen.

Das wäre dann ein Mechanismus Workflow-Orchestrierung (die in Kitodo verbleibt) und Prozess-Ausführung bei Bedarf teilweise zu separieren, ohne direkt die Workflow-Engine neu konzipieren zu müssen (siehe #4137 (comment) )

[henning-gerhardt]

Lieber Christoph,

vielen Dank für deine ausführliche Antwort.

Deine Punkte sind alle gut und bei vielen gehe ich auch mit, aber du weitest das Thema sehr aus, wobei ich nur ein ganz klar abgegrenztes Thema angehen / diskutieren wollte. Das im Umfeld vom Taskmanager und dessen Nutzung noch viel mehr Baustellen sind, ist ein anderes Thema, auf das ich mich hier nicht fokussieren will. Dazu müssten einmal die unterschiedlichen Anforderungen und Verbesserungswünschen, die bei den verschiedenen Nutzern existieren, zusammen getragen werden und dann diese diskutiert werden, wie man viele (vermutlich nicht alle) mit einer besseren und nachhaltigeren Lösung zusammen bringt. Die Ausführungsmodi der Shell-Scripte bzw. extern ausgeführten Programme sind dann natürlich auch Bestandteil davon.

[BartChris]

Lieber Henning,

sorry, da bin ich wohl schon zu weit in die Lösung gesprungen. Das Problem an den Shell-Skripten ist, dass sie in unterschiedlichsten Szenarien zum Einsatz kommen, was dann schnell grundsätzlichere Fragen aufwirft, sobald man über die Lösung spricht. Daher muss man hier evtl. auch etwas Erwartungsmanagement betreiben:" Was kann Kitodo und was kann es (noch) nicht?" Um bei der Ursprungsfrage zu bleiben:

• Berücksichtigt werden sollte vor allem, dass Einrichtungen teilweise sehr viele Skripte im Rahmen eines Workflows parallel ausführen und man dafür ein Ausführungsmodell diskutieren muss. (gewünscht ist das auch für die erste Aufgabe: Script task as first task is not started #3672) Das ist aber wohl ein schwierigeres Problem.

Ich bin aber ganz dafür zu eruieren, wo man in einem ersten Schritt "den Hebel ansetzen" kann, um inkrementell Verbesserungen zu erreichen.