AE11.2: FileEvent - Laufzeitfehler

[Manfred Mauermann]

Guten Morgen zusammen,

 

so langsam entwickelt sich der FileEvent zu einem meiner Lieblingsthemen.... Wollte gestern einen Test durchführen, den ich zwei Wochen zuvor schon erfolgreich rauf und runter getestet habe, und plötzlich verweigert dieser die Kooperation.

 

Letzte Meldung U00010038 Laufzeitfehler: Datensequenz 'FILETRANSFER' konnte nicht erstellt werden. Status: '0000001820', Rückgabewert: '0000000000'.

                      Max. parallel               1

                      processing    EVNT.ABC#MTXYZ.DZ@FILEEXISTS

                                00002 - > : SET     &datumhnd# = PREP_PROCESS(&host#,"UNIXCMD","*","CMD=find '&in_absolut#' -name &inputpattern#",,"UC_LOGIN=UNIX_UC4")

 

Wir haben eine Hostgruppe mit zwei Servern (Linux Red Hat 7), was das eigentlich spannende ist, da es auf dem 1. Server immer fehlschlägt und auf dem zweiten generell funktioniert. Vor zwei Wochen war das noch kein Problem. Dazwischen war unser RHEL7-Patchday, wobei lt. Provider beide Server den identischen Versionsstand haben. UC4-seitig ist mir kein Update/Hotfix bekannt.

Der aufgelöste find funktioniert auf beiden Servern problemlos.

Den &in_absolut hatte ich sowohl mit als auch ohne Hochkomma getestet, da bekam ich von einem Kollegen einen entsprechenden Hinweis, das war aber ohne Auswirkungen.

Auch die Variablen sind korrekt befüllt und im Moment stehe ich auf dem Schlauch. Habe dazu eben auch bei unseren DevOps ein Ticket eröffnet, wollte aber parallel dazu die Frage in die Runde werfen, ob hier schon jemand ein ähnliches Phänomen hatte und vielleicht sogar einen Lösungsansatz parat hat.

Meine erste Vermutung ging noch in Richtung Berechtigungen, da hier für unsere geplante 12.1 Migration Änderungen durchgeführt wurden, dann dürfte es aber auf beiden Servern nicht laufen.

Hier der Vollständigkeit halber noch die Meldungsausgabe, das mit dem ReadFileAuthority() klingt zwar interessant, wird aber vermutlich ein Folgefehler sein.

 

07.06.2018 08:22:06 -  U00010038 Laufzeitfehler: Datensequenz 'FILETRANSFER' konnte nicht erstellt werden. Status: '0000001820', Rückgabewert: '0000000000'.
07.06.2018 08:22:06 -  U00011045 Die Bearbeitung des Ereignisses 'EVNT.ABC#MTXYZ.DZ@FILEEXISTS' (RunID: '0733215909') auf Host 'UC4-1.INTEG' wurde mit einem Fehler beendet, siehe nachfolgende Meldung:
07.06.2018 08:22:06 -  U00029003 Die Datei '/home/uc4executor/ECJSNFQB.TXT(ReadFileAuthority())' kann nicht geöffnet werden, Fehlercode '2', Fehlerbeschreibung: 'No such file or directory'.
07.06.2018 08:22:06 -  U00011000 'REPORT'  (RunID: '0733226047') konnte auf 'UC4-1.INTEG' nicht gestartet werden. Siehe nachfolgende Meldungen:
07.06.2018 08:22:06 -  U00011003 Job 'EVENT.UNIXCMD' (RunID '0733221790') auf Host 'UC4-1.INTEG' ist abgebrochen (Rückgabewert='0000000001'). Remote-ID=63542

 

Vorab schon mal vielen Dank und viele Grüße

Manfred

 

[Legacy User]

Manchmal ist es hilfreich, das EVENT.UNIXCMD in seinen Mandanten zu kopieren und in diesem Objekt für die Diagnosephase den Report in die DB zu aktivieren. Ist im gelieferten Objekt ausgeschalten, was ja auch Sinn macht.

Es sollte nun auch das Resultat zu sehen sein, dass man sich vom find erhofft.
Liefert das Kommando nichts zurück oder läuft auf einen Fehler, wird ja keine event ausgabe datei erzeugt und das würde genau die Fehlermeldung erklären - "no such file or directory".
 

[Manfred Mauermann]

Eine sehr gute Idee, Danke! Hab das eben ausprobiert, und bekomme aber lediglich Unterschiede beim Returncode im Trailer:

************************************************************************
**  ucxjlx6m   version 11.2.2+build.622         changelist 7627775    **
**  JOB 733254460 (ProcID:0000052380) ENDED AT 07.06.2018 / 10:24:25   **
**                                   UTC TIME 07.06.2018 / 08:24:25   **
**  TEXT="        Job beendet             "  RETCODE=00               **
************************************************************************

und im Fehlerfall auf dem 1. Server:

************************************************************************
**  ucxjlx6m   version 11.2.2+build.622         changelist 7627775    **
**  JOB 733252921 (ProcID:0000001759) ENDED AT 07.06.2018 / 10:26:18   **
**                                   UTC TIME 07.06.2018 / 08:26:18   **
**  TEXT="        Job beendet             "  RETCODE=01               **
************************************************************************

Ansonsten im Übrigen keine Ausgabe....

[Manfred Mauermann]

Sieht mir nicht wirklich nach einem UC4-Problem aus, ich habe mir einen Test-Event mit einem ganz normalen echo geschrieben, der funzt einwandfrei. Das mit dem Report aktivieren war wirklich ein sehr guter Tip, Danke nochmal an zalfr01

[Manfred Mauermann]

Das Problem ist umzingelt, es liegt tatsächlich am find. Der reagiert im user uc4 anders als im user uc4executor, mit dem die Jobs ausgeführt werden. Und das auch nur auf dem 1. Server

Identische find-Version, dieselbe "ls -l" Ausgabe, dieselben Gruppenrechte

Funktionieren tut das Ganze, wenn das Dateipattern (" oder ') gequoted wird.

 

[uc4executor@uc4-1~]$ find ./mt940/in/ -name sap_bca_mt940_????????.????????????.txt.ssl
find: paths must precede expression: sap_bca_mt940_20180529.145138000339.txt.ssl
Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression]

 

[uc4executor@uc4-1~]$ find ./mt940/in/ -name 'sap_bca_mt940_????????.????????????.txt.ssl'
./mt940/in/sap_bca_mt940_20180606.094653000982.txt.ssl

 

Wenn ich überlege, wie viele FileEvents wir mit nicht gequotetem Dateipattern im Einsatz haben, werde ich etwas nachdenklich....

[Legacy User]

Ich würde ja vorschlagen statt dem PREP_PROCESS UNIXCMD, den PREP_PROCESS_FILENAME zu verwenden. Macht eigentlich das selbe wenn ich nur den Dateinamen benötige. 
Link zur Doku: Automic 

[Manfred Mauermann]

Wäre tatsächlich besser, das ist richtig. Die neueren Objekte nutzen den tatsächlich schon teilweise. Aber es sind ja noch etliche ältere unterwegs und damals war das irgendwie die erste Wahl.

[Manfred Mauermann]

Muss leider zugeben, dass ich wohl ein paar Basics bez. Globbing der bash erfolgreich verdrängt hatte. Gehört trotzdem in Kategorie "kleine/große Gemeinheiten in der IT"....

Die Lösung: Im Home-Verzeichnis des besagten users auf dem besagten Server befanden sich Dateien, die zum vorgegebenen Dateipattern passten. Das Pattern im find wurde bereits vor der Ausführung mit diesen Dateinamen ersetzt und führte somit zu dem Syntax-Fehler. Schwer erkennbar, weil auch nur ein Dateiname in der Fehlermeldung ausgegeben wurde. Und das Home-Verzeichnis im ersten Moment auch keiner von uns im Blick hatte. Alte Testdateien von einem Kollegen. Tja, keiner löscht was. Andererseits natürlich ein wertvoller Hinweis auf eine Problemstelle, die für ordentlich Unruhe im Betrieb sorgen kann.

Nächste Aufgabe ist das Quoten aller Dateipattern in allen FileEvents bzw. find-Kommandos.

[FrankMuffke]

Lei lei

 

kurze Anmerkung dazu, es ist -finde ich- ein gravierender Designfehler seitens Automic

 

Langer Leidensweg in kurz:

in der EVNT.UNIXCMD wird das ergebnisfile einfach gelöscht, sollte ein RC>0 vom OS kommando zurückgegeben werden.

Daher kommt auch die ominöse File not found Fehlermeldung, die eigentlich total am Ergebnis vorbeizischt und das Ganze noch verwirrender macht.

Ausserdem wird das Ganze mit einem FAULT_OTHER beendet, was sowieso Schwachsinn ist, da es sich um keinen Scriptfehler handelt,sondern um einen RC >0, der vom unix zurückkommt....

 

 

Abhandlung hier:

PREP_PROCESS ends up in a 'No such file or directory' error if the OS command returns RC > 0 

 

 

lg Wolfgang

[Manfred Mauermann]

Danke für die Info und den Link Wolfgang, damit wird das Verhalten noch verständlicher. Dagegen ist ja ein "2>&1>/dev/null" direkt langweilig. Man kann Automic aber nicht vorwerfen, sie hätten sich dabei keine Mühe gegeben

 

lg Manfred