AWA 12.1: Verhalten bei Beendigung eines UNIX-Jobs mit "exit $var"

[Manfred Mauermann]

Hallo zusammen,

 

hab schon wieder eine Kiste für die 12.1, die mir ein bisschen Sorge bereitet. Wir beenden unsere Unix-Jobs für die REST-Aufrufe immer mit einem "exit n", um Fehler zu erkennen. Da hat sich jetzt zwischen 11.2 und 12.1 anscheinend das Verhalten geändert.

 

Es funktioniert weiterhin problemlos:

exit n

Was nicht mehr funktioniert, ist folgendes Konstrukt:

rc=9

ecit $rc

Der Prozess bricht mit dem Status "ENDED_VANISHED - verschwunden" ab.

 

Kennt diesen Effekt schon jemand?

Wäre natürlich ein größerer Aufwand, das z.B. mit :REGISTER_VARIABLE und Post-Skript abzufangen.

 

Vorab Danke und viele Grüße aus Nürnberg

Manfred

(der einzige im Stockwerk, alle anderen sind auf Dach und gucken DTM-Fahrertraining)

[Manfred Mauermann]

Mal zwischendurch die Erkenntnis, dass auch andere Kunden das Problem hatten. Konnte auf der CA Summit zwei ausmachen, wo es auch Lösungsvorschläge gab. Der Automic Support konnte den Fehler zwar nicht reproduzieren, aber mit den beiden folgenden Methoden sollte man den Fehler vermeiden können:

1. Den "exit $rc" in ein bash-Skript verlagern
2. Über HEADER.UNIX soll es möglich sein, den Prozess in einer Subshell laufen zu lassen

Muss aber beides erst verifizieren, derzeit kämpfen wir immer noch mit dem Lizenzthema zur 12.1

Jetzt ist aber erst mal eine Woche Urlaub angesagt

lg aus Nürnberg

Manfred

[FrankMuffke]

Lei lei,

Es gab mal 2 Diskussionen über das Thema - Vorraussetzung - es ist kein neuer Bug...

 

https://communities.ca.com/message/242102440?commentID=242102440#comment-242102440 

 

https://communities.ca.com/message/242090721?commentID=242090721#comment-242090721 

 

mglw. hilft das ja - zumindest, wie sich das Ganze verhalten soll....

 

lg Wolfgang

[Manfred Mauermann]

Hallo Wolfgang,

 

Danke, die Links waren für mein Verständnis nochmal gut zum nachlesen. Wir werden die Lösung mit:

(exit $rc)

nehmen, da natürlich nicht alle Scripts mit exit beendet werden und auch nicht in jedem Script die Variable $rc gesetzt wird. Das sind letztlich überschaubare Änderungen und im Vergleich zum Lizenzthema fast schon Entspannungsübungen. Die Agents laufen seit Freitag bis jetzt erstmals stabil. Betonung liegt bei letztem Freitag. Das Thema hat uns 4 Wochen Testzeit gekostet Absolut unschön!

 

lg Manfred

[Manfred Mauermann]

Hab das jetzt nochmal unter der 12.1.2 verifiziert

1. #!/bin/bash
   rc=0
   echo "rc:$rc"
   (exit $rc)
2. #!/bin/bash
   rc=9
   echo "rc:$rc"
   (exit $rc)
3. #!/bin/bash
   rc=9
   echo "rc:$rc"
   exit $rc

 

Die Automic-Kollegen auf dem CA Summit konnten das in dieser Form leider nicht reproduzieren. Aber ok, mir ist an dieser Stelle eine praktikable Lösung am wichtigsten.

[Manfred Mauermann]

Klasse , jetzt funktioniert der "normale" exit n auch nicht mehr. Vermutlich seit 12.1.2. Und irgendwie wird der Ende-Status nicht gesetzt, sodass er im Post-Skript nicht mehr abfragbar ist.

 

Ende vom Job-Report (kein Trailer vorhanden):

I N F O: Liste der Dateien ist nicht leer, Dateien wurden gefunden.

exit 101

 

Auszug aus dem Report vom Post-Processing:

2018-07-11 11:31:10 - U00020408 returncode: 0

2018-07-11 11:31:10 - U00020408 I N F O: Returncode ist ungleich 101, Transfer-Jobkette wird nicht getriggert.

 

Post-Skript:
:SET &returncode# = GET_UC_OBJECT_STATUS ( , , RETCODE )
:PRINT 'returncode: &returncode#'
:IF &returncode# = 101
:  SET &object_to_start# = &name_transfer_jobplan#
:  PRINT 'object_to_start: &object_to_start#'
:  INCLUDE SHARED@START_IF_NOT_RUNNING
:  MODIFY_STATE RETCODE = 0
:ELSE
:  PRINT 'I N F O: Returncode ist ungleich 101, Transfer-Jobkette wird nicht getriggert.'
:ENDIF

 

 

Ticket ist im Übrigen offen, wir warten auf den Support......

[Manfred Mauermann]

Halleluja, wir haben die Lösung. Unerwartet und in der Nachbetrachtung, wie so oft, recht simpel. Der erste Workaround war ja der Downgrade auf die 11.2 Agenten. Dann kam der Hinweis vom Support auf einen Parameter "starttype".

Ja, und der wars dann auch. Da war der Wert "batch" anstelle von "fork" zugewiesen.

Dann ist auch das Verhalten ganz klar, bei "batch" ist der Prozess völlig entkoppelt, der Server ist auf die Rückmeldung vom Jobmelder angewiesen, welche natürlich bei einem exit ausbleibt.

Bei "fork" bleibt die Verbindung bestehen, der exit beendet und gibt an den Parent den korrekten exitcode mit.

 

So einfach kann die Welt sein. Na dann auf in die nächste Runde