You are here: Foswiki>Applications Web>AppOnCallDutyMain (07 May 2020, JuttaFitzek)Edit Attach

On-call duty / Rufbereitschaft - Main Page

These pages collect necessary information for on-call duty. Relevant information about system access, location of log files, restart/reboot operations and support for specific applications is all collected or linked here.

0. General information

Handout Rufbereitschaft

How-To: Arbeitszeiten und Rufbereitschaft

Duties additionally to actual on-call duty

  • Visit HKR once or twice a day and ask for issues. Spend more time there in case of problems.
  • Monitor OLOG entries
    • Shift and technical defects (Shift and Cone icon)
  • Visit the "Mittagssitzung" (12:45Uhr, Kühlschrank) and be ready to report about APP OLOG entries
  • Visit "OCM Meeting" on wednesdays (9:00Uhr, Kühlschrank) if neither JF nor HH is going, be ready to report on issues listed in the Technical Defect Report (OLog Login required)


1. System access

1.1 Citrix (works fine)

Citrix: Use your computer at home and with the Citrix client Software to access GSI. To enable Citrix access follow these instructions.

From the Terminal Server to which you logon, you can then use either Remote Desktop to your Windows machine or X-Win-32/X2go to the Linux Cluster.

1.2 X2Go (works fine)

See AppOnCallDutySystemAccessX2Go .

1.3 Remote Desktop (works fine)

To get to your own machine through lx-pool, you can use a ssh tunnel. On MacOS or Linux, entering the following command on the command line:
ssh -L

where 54321 is an arbritray local port, and belpcxxx is your machines hostname. On Windows, Putty provides similar functionality (and probably other tools as well).

Then, you can run a remote desktop client directly from the machine where you opened the tunnel. Be sure to specify the locally mapped port (54321 in the example above) as the one to connect to. From a windows environment, you can use Remote Desktop, from a Linux environment rdesktop. To enable remote desktop access follow these instructions.

1.4 Igel ThinClient (works fine, but lacking features)

Using a dedicated box at home provided by GSI IT, the Igel ThinClient. Via VPN you are directly connected to a GSI Windows Terminal Server. This solution works fine, however since it is only a ThinClient, Media like Webcam etc. is not supported. For Video Conferencing you need additionally e.g. your private computer.

1.5 System access to the development or production cluster

From inside the GSI environment, you can use XWin32/X2Go from Windows systems or ssh -X from linux systems to access the asl cluster (currently asl7xx for development and asl3xx for production).

1.6 Working locally using linux based host OS

To work on a local machine one can tunnel all services throug lx-pool using ssh. The script provided by Andreas simplifies the needed steps. However, when starting applications this might become a bit slow campared to remote desktop sessions since more context information need to be donwloaded to the local host.

1.7 HowTo mount the windows file share on the asl7xx cluster

See AppOnCallDutyWindowsShareOnCluster .

2. Misc

2.1 Tools

For readout of FESA devices, the FESA Explorer can be used:

The Prophelper for readout of Device Access devices can be started as follows: Remember to select the virtual accelertor, which corresponds with the sequence number (at least 2018).

Tool to show device informations:
/common/usr/cscofe/bin/pdex GS12MU3I Setting -s p3

Tool to show LSA context informations:

# on the dev cluster asl4xx - shows pro information
/common/usr/lsa/bin/lsa_residump [-t]

Alternatively open:

3.0 DeviceControl

Annotations to the icons and colors of device status can be found in Status-Guideline.

3.1 Tool To Access To Devices:

(If DeviceControl is connected to the frontend controller, FESA devices and DeviceAccess devices can be distinguished by the status format in status dialog: From Detailed status Bit 8 the status texts have grey background.) The tools can be used for readout, but also for setting. At the latter you have to use the write command instead of read command.

3.1.1 FESA-Explorer (FESA devices)

To use the FESA Explorer proceed as follows:
  1. use script "fesa-device-info -p devicename "
    You'll get a table with FESA info of the device. You need the info on column "Deploy-Unit.FEC"
  2. call the FESA-Explorer: /common/usr/lobi/bin/fex &. (GUI will open)
  3. select pro environment: dropdown-box on top
  4. press icon leftmost ot load model from disk and look for the zip-file. The name is that of the content in the table of the FESA device info in 1.
  5. select the zip-file and confirm with open.
  6. "Device selection" (upper left): all devices being controlled by the selected FEC are visible
  7. select the device by double click
  8. "Cycle selection" (middle left): Select the context required for device access. Use "any" (default) for non-multiplexed, otherwise select the required context details for multiplexed properties.

    Attention: if you change the context, please remember to confirm by click on button "Change" (middle top)

  9. "Property selection" (bottom left): all properties defined for the selected device are visible. Following types rendered by various icons:
    • Command properties (executing has to be confirmed)
    • Setting properties
    • Acquisiton properties (Get/Set/Subscription)
Attention: Remember to change the conext if you look for multiplexed (e.g. Acquisition) and non-multiplexed (e.g. Status) properties.
  • Configuration Select property by double click. "Fields"-view (middle top) with all defined properties and the respective values (if exist) opens. Everything else should be obvious.

3.1.2 Equipstate (start by launcher)

Proceed as follows:
  • select context or accelerator zone, device group, device, and finally the property you want to read/write
  • : Attention: Execute readout request per property before a write request.

EquipState uses JAPC framework, FESA-Explorer does not!

All FESA devices use property Status and Power(if necessary).

Specific FESA devices using setting properties by DeviceControl:
  • MotorClass (Steppermotor):
    • Setting (input: numerical)
    • MoveToPosition (input: named position)
    • ToEndPosition (input: 0 = Outer end position, 1 = inner end position)
  • PneuDrive2018 (Pneumatic drive):
    • SettingMode
    • Setting

3.1.3 pdex

Devices have to be online!

All DeviceAccess devices use property INFOSTAT (status) and POWER (if necessary).
  • infostat (no selection of virtacc required)
  • power (no selection of virtacc required)

As reference for reading current device' values use

pdex GS12MU3I -d


pdex GS12MU3I a

(s.a. pdex).

3.2 Interesting Code (trunk-version)

model.domain (= JAPC-interface of (FESA) devices]: Devices are roughly structured by (FESA)device types (e.g. PneumaticActuator, exception: DevCtrlMagnJAPC contains several PowerSupplies, e.g. Bumper, Electrostatic septum, etc.). The name of device type should be intuitive (e.g. DevCtrlChopperJapc). :
  • superclass (of device classes): AbstractJAPCDevice: all common methods and definitions (AbstractJAPCDeviceDefinitions) for devices controlled by DeviceControl application
  • deviceAccessControl (DeviceAccess classes) are always nested in the particular "FESA" device class, (.i.e. DevCtrlSlitJapc object generates SlitCollimatorDeviceAccessControl object and should not be used outside these device classes).
  • DevCtrlJapcApi: JAPC-interface in DeviceControl
  • !LsaDeviceWrapper: (DeviceControl-)classification of (LSA-)device.
  • Steppermotor/SlitWidget: SlitWidgetDialog
  • Driving Actuator/Gate valves: ActuatorDialog

3.3 Using the PictoView

  • use the filters to reduce the visible picto buttons (e.g. click "Keine Icons auswählen" and click then the devicetype filter of pneumatic actuators (if currently existing))
  • The output "x von y Geräten gewählt": y denotes the number of available devices (i.e. the devices having already responded on subscription. Therefore y can be updated.)
  • Each button in the chain navigator line represents a device being controlled by ACO. (Nearly) each device is characterized by a pictogram icon to facilitate the identification of device. So every drivable device (i.e. gate valves, pneumatic actuators, and steppermotors) do have a fittingly pictogram icon.
    ATTENTION (concerning only DeviceAccess devices): If there is a (drivable!) device button without pictogram button no status type is defined. Instead, only common status details and no current beamline position will be considered. Remedy: An entry in device-control-app-OperdbInfo.csv ( has to be generated. If no specific details are known they can be copied by an equivalent device entry in this file!

3.4 What to do

  • Device is not visible in AppApplicationDeviceControl:
    1. check if device is known (Frontend):
    2. if device is known by Frontend, check if device is known in LSA and an "actual" device (e.g. by sqldeveloper)
      select d.DEVICE_NAME, dt.DEVICE_TYPE_NAME from DEVICES d
      where d.DEVICE_NAME like 'GTH2DI2SP%' and dt.LOGICAL_ACTUAL_BEAM like 'A%';
    3. if device is known by LSA, check if (LSA-)device type is known
      1. get device type
      2. LsaDeviceWrapper: check in checkDevice() resp. checkDeviceAccessTypes(), if devicetype is supported by AppApplicationDeviceControl
  • Device status not updated:
    • select device PictoButton and click "Status": Current status timestamp is shown (Hint: at least when opening the status dialog the timestamp should be the most current, received by DeviceControl. Until now it has not been checked, if timestamp is always updated, so performance issues cannot be suspended then. It can definitely take a long time (ca 30 sec) to update the timestamp!)
  • Driving job is hanging (i.e. rendering of throbber icon table view is not stopped). Select another context and reselect then the previously selected context (to cancel the request). If this does not work (then it is a bug I have to fix) restart DeviceControl.
  • ActuatorWidget, SlitWidget: driving impossible: drive actuator (DeviceAccess, FESA see next item)/gate/steppermotor/slit devices by alternative tools (prophelper (DeviceAccess), EquipState (FESA) by using setting properties described above.
  • ActuatorWidget: driving of FESA devices impossible: Crying team prefers using of LOBI application for driving FESA pneumatic actuators. If this is not possible use EquipState: check if value of parameter 'modeSet' of command 'Acquisition' is 1 (=REMOTE). If value of parameter 'modeSet' is 0 (=IDLE), write value = 1 (=REMOTE) in parameter 'mode' of command 'SettingMode'. If value of parameter 'modeSet' is not 0 (=IDLE) nor 1 (=REMOTE) the mode has to be set first to 'IDLE' by Cryring team (or by LOBI). Then the pneumatic actuator can be driven to the requested position by DeviceControl resp. EquipState. In latter case use command 'Setting' and write parameter 'setPosition': 0 (=OUTSIDE) or 1 (=INSIDE).
  • SlitWidget: Incomplete rendering of widget, e.g. no gray bar rendering the actual position:
    • reopen the slit widget dialog
  • Antriebe/Schrittmotor nicht angemeldet (roter Gerätebutton mit gezogenem Stecker) : (Fehler 202158146: Number of connections exceeded, connection not established.) Mit dem Aufruf von
    /common/usr/cscofe/bin/conndesc GTS2DI1PP
    (anwendbar auf DeviceAccess-Geräte) kann man die aktuellen Subscriptions ermitteln, inkl. der Konsole, auf dem der zugehörige Subscription-Client gerade läuft. Ggf. Clientprozess beenden und AppApplicationDeviceControl erneut starten.

3.5 Error messages

  • "XML for ...xml could not be found": can be ignored (minimum version of equipment model is not available)
  • "Ungültiger Prozesskey":
    • FESA device: Process key of device and of fair-selector do not agree
    • DevAcc device: Sequence ID of device and fair-selector sequence ID do not agree
  • "The field 'acqDataArray' has no data for the cycle selector ... (no set was done before calling get)..." (Status- resp. ValueWidget) No data supply had been done until now for the device.
  • GS00ZGT unsupported device type: TGX: latestVersion=DeviceTypeVersion[deviceType=TGX, versionNumber=4.0, implementation=DEVACC] can be ignored (no need of device in DeviceControl)
  • GS09DT_S unsupported device type: ACCT: latestVersion=DeviceTypeVersion[deviceType=ACCT, versionNumber=0.1, implementation=FESA3] can be ignored ((at least currently) no need of device in DeviceControl)

3.6 HowTo

  • check, if device is FESA or DeviceAccess:
    • search device in FESA tool (e.g. FESA explorer) or DeviceAccess tool (e.g. prophelper) or
    • click on "Status"-Button: Status dialog opens. If detailed status texts are to be seen: German texts = DeviceAcces, Englisch texts = FESA. Besides FESA devices have detailed infos to module status.
  • driving steppermotor/slit device by slit widget (only horizontal or vertical axis):
    • insert setting value:
      • furthermore outside icon buttons: inner/outer end position (depends on location (left/right/top/bottom) and axis (horizontal/vertical))
      • inner icon buttons: fine tuning (increment 0.1 mm)
      • text field: numerical input mm-unit, finish with "enter"
      • move cursor knob in diagram (if cursor is invisible propably the actual position is outside the acceptable range or not known)
    • any inconsistenies/irregularities:
      • reopen the slit widget dialog
    • debugging driving process: start application by setting System property "", e.g. as VM-argument. The setting positions will NOT be sent to the device then. (Code entry: DeviceTablePanelController: executeDeviceSelection(...))

4. SchedulingApp

  • Ändern des Schedules (PatternGroups)
  • Anlegen neuer Patterns

4.1 Screen 1: Ändern des Schedules (PatternGroups)

  • Änderungen am Schedule vornehmen, dann oben rechts "Versorgen/Supply" drücken => LSA versorgt Geräts und BSS!
  • Supply in mehreren Schritten:
    1. Patterns resident machen + Drive der zugehörigen Settings zu Geräten
    2. PatternGroups aktualisieren (Patterns raus, Patterns rein/Reihenfolge ändern, leere PatternGroups löschen)
    3. Patterns non-resident machen
  • Bei Fehlern beim Supply oder beim Abbruch durch User bei Drive-Fehlern wird versucht, den vorherigen Schedule-Zustand wiederherzustellen (="Undo-Supply").
Hier könnten typischerweise Fehler auftreten, die mit LSA und den BSS-Komponenten zu tun haben.

4.1.1 Interessanter Code bzgl. Supply
  • ScheduleManagementController#handleSupply - anstoßen des Versorgungsvorgangs aus GUI
  • SupplyScheduleChangesTask - Schritte beim Supply, Loggen in die Anwendungskonsole, Handhaben von"Undo-Supply"
  • SupplyHelper - Details der einzelnen Schritte, insbesondere #updatePatternGroups ist etwas komplexer

4.1.2 Tipps im Fehlerfall Was tun, wenn Probleme beim Ändern des Schedules/Versorgen auftreten?
  1. Alle Patterns auf einmal ausplanen (alle aus Schedule entfernen, Supply drücken)
  2. Im SnoopTool kontrollieren, das nichts mehr läuft (SCU ZT00ZM01 oder alternativ ZT00ZM02)
  3. Gewünschte Patterns wieder einplanen
Wenn die Schritte nicht möglich sind oder in Schritt 2 festgestellt wird, dass noch Events gespielt werden, obwohl alle Patterns erfolgreich ausgeplant wurden, liegt höchstwahrscheinlich ein Problem mit BSS vor (-> Fehlermeldungen anschauen).

NUR in Absprache mit der Services-Rufbereitschaft: Vollständiger oder teilweiser Reset von BSS und LSA.
Falls der Generator/Data Master nicht resettet wurde (Services-RB fragen!), könnte es sein, dass anschließend noch Events gespielt werden, das ist in diesem Fall ok.) Was tun, wenn für eine PatternGroup kein Timing läuft (keine Events gespielt werden)?

Manchmal hilft es, ein einzelnes Pattern aus der betroffenen PatternGroup aus- und wieder einzuplanen. Damit wird der betroffene Timing-Core neu versorgt.

4.2 Screen 2: Anlegen neuer Patterns

  • Settings werden über mehrere Schritte in Chains/Pattern getrimmt - recht komplex
Hier könnten typischerweise Fehler auftreten, die mit LSA-Trims und dem Datenmodell zu tun haben

4.2.1 Interessanter Code bzgl. Trimmen
  • PatternEditorController#trimSettings und daraus aufgerufene Helfer-Klassen/-Methoden bzgl. Erzeugen neuer Chains
  • CopyStandAloneChainAndInitIfNecessaryTask und InitTemplateChainHelper bzgl. Einbauen von Chains in Patterns
  • UpdateChainsInPatternTask und ContextGenerationHelper#createPattern

5. BSS Control

  • Setzen von RepetitionCounts für Patterns
  • Signale setzen, die Ausführbarkeit von Patterns steuern
Hier könnten typischerweise Fehler auftreten, die mit LSA oder BSS (insbesondere Komponente !RequestProcessor) zu tun haben. Außerdem wird mit Hilfe einer Subscription der MASP-Status abgefragt.

5.1 Tipps im Fehlerfall

  • Information für MASP ist unknown (grau): Graylog prüfen, ob Probleme mit Subscription vorliegen. Prüfen, ob MASP läuft (z.B. MASP-Gui / Interlock-Programm). Wenn der Verdacht besteht, dass der MASP nicht läuft/keine korrekten Daten liefert etc.: Timing-RB.
  • Informationen für Signals sind unknown (grau): Graylog prüfen, ob Zugriff auf RequestProcessor -REST-API funktioniert. Wenn der Verdacht besteht, dass der RP nicht läuft/keine korrekten Daten liefert etc.: BSS-RB (Services)

6. RequesterApp

  • Anforderung von Strahlzielen: Daueranforderung (jede Ausführung, die möglich ist), Einmalanforderung (genau einmal ausführen (unter Berücksichtigung des Repetition Counts!)), Anforderung zurücknehmen/abbrechen
Hier könnten typischerweise Fehler auftreten, die mit BSS (insbesondere Komponente !RequestProcessor) zu tun haben, und mit der Konfiguration von Strahlzielen.

6.1 Konfiguration von Strahlzielen

Im Config-File der RequesterApp auf websvcdev/websvcpro (/common/usr/cscoap/htdocs/config/ wird konfiguriert, welches Strahlziel auf bestimmten Rechnern/Konsolen angefordert werden kann:


Achtung: HKR- und Experiment-Konsolen ohne, ASL-Maschinen mit !

Achtung: Dumps (z.B. HHD) sind implizit immer angefordert, sie sind nicht an-/abforderbar. Es ergibt daher keinen Sinn, sie auf Rechnern als Strahlziel zuzuordnen.

Eine erfolgreiche Zuordnung erkennt man daran, dass die RequesterApp unter "Strahlanforderung" gut sichtbar das jeweilige Strahlziel (z.B. HTP) und mehrere Buttons für die Anforderung anzeigt, wenn sie auf einem bestimmten Rechner gestartet wird. Fehlt im Config-File die Zuordnung für einen bestimmten Rechner, so fehlt in der Anwendung, wenn sie auf dem betreffenden Rechner gestartet wird, sowohl die Anzeige des Strahlziels als auch die Buttons. In der Anwendungskonsole sollte eine entsprechende Fehlermeldung erscheinen, z.B. "Für Konsole [Rechnerbezeichnung] wurde kein zugeordnetes Strahlziel gefunden, fehlende Konfiguration." o.Ä. .

7. ParamModi

7.1. Parameter werden auf ParamModi-Tabs nicht angezeigt

  • Prüfen (auf ParamModi-Tab mit Hilfe der Suche/Filter-Funktion): Wird Parameter evtl. unter Total-Tab angezeigt, nur nicht auf dem gewünschten Tab? Wenn ja: Sollte ausreichen als Workaround, ggf. Verweis auf LSA-DV-RB wenn Behebung gewünscht (nach Behebung evtl. Release von app-common-lsa-utils und app-parammodi mit angepasster Abhängigkeit notwendig)
  • Prüfen (Trim-Tab oder DB): Sind Parameter in ParameterGroup "generation"? Wenn nicht: Fehlerhafte Modellkonfiguration, LSA-DV-RB
  • Prüfen (DB): Gibt es Parameter-Konfigurationen (GSI_APP_PARAMMODI_CONFIG) für die betreffenden Parameter? Wenn nicht: Fehlerhafte Konfiguration, Verweis auf LSA-DV-RB für Behebung(nach Behebung ggf. Release von app-common-lsa-utils und app-parammodi mit angepasster Abhängigkeit notwendig)
  • Prüfen (ParamModi bzw. Logstash): Gibt es Fehlermeldungen (Warnings, Errors) bzgl. fehlender Konfigurationen für die betroffenen Parameter/Gruppen/Tabs?

7.2. Neue Parameter einbauen

  • common-lsa-utils-uilib (Oberflächentexte)
  • parammodi-app
  1. common-lsa-utils-uilib releasen
  2. Abhängigkeit in parammodi-app hochziehen
  3. Reguläres App Release von parammodi-app
  4. Parammodi Instanzen im HKR schließen und neustarten lassen

8. Zusammenarbeit mit Timing-Rufbereitschaft

  • Gespräch mit Dietrich und Michael (Matthias ist derzeit krank, Montag, 11.06. wieder da)
  • INIT ist Grenzfall, kann aber auch von kompetenten APlern gemacht werden, man sollte wissen, was man macht
  • "Durchcyclen" führt im Gegensatz zu Init zu Datenverlust, spätere Analyse schwieriger
  • "Durchcyclen" oder FCGA-Reset sollte nur von Timing Gruppe durchgeführt werden

9. LSA

Fehler aus LSA können verschiedene Ursachen haben:
  • Model (David & Co.)
    • Fehlermeldungen wie "out of limits"
  • Netzwerk
    • Fehlermeldungen wie "Method Invocation Exception" (RMI Fehler)
      • Anwendung neustarten
      • prüfen ob LSA-Server läuft (meist auf asl341)
        ps -u belsvc -o pid,%cpu,%mem,lstart,command
      • Abhängigkeiten (Versionen von LSA) überprüfen
        • entweder unter About in der Anwendung (falls verfügbar) oder /common/usr/cscoap/htdocs/applications/<app-name>/current/lib
      • SErver neustart (falls nötig) über IN Rufbereitschaft
  • Performance Probleme
    • Datenbank auf hängende Jobs überprüfen (evtl IN Rufbereitschaft)

Wenn kein Timing läuft (überprüfen mit Snoop-Tool)
  • BSS
    • signale überprüfen
    • Neustart (wenn nötig) über IN Rufbereitschaft
      • anschliesend Vollversorgung aus Scheduling App
  • MASP überprüfen
    • Beam Modes korrekt gesetzt? (in ParamModi suchen nach beam_mode)
    • Neustart (wenn nötig) über IN Rufbereitschaft
      • anschliesend Vollversorgung aus Scheduling App
  • Patterns aus und wieder einplanen
    • DM status über FESA-Explorer (cmwpro00a -> tsl017)

9.0. LSA Server Release

Folgende Projekte sind zu releasen:
  • lsa-ext-fair-gsi
  • lsa-server-gsi
Bei RB wird idR. nur "lsa-ext-fair-gsi" geändert (Modell, Berechnungen). Einfache Bugs (z.B. Javadoc-Bugs, ggf. auskommentieren) fixen. Wie folgt vorgehen:
  1. pull von lsa-server-gsi und lsa-ext-fair-gsi
  2. lsa-ext-fair-gsi: mvn release:prepare release:perform
  3. uU. java docs fixen oder kommunizieren
  4. lsa-server-gsi: lsa-ext-fair-gsi Abhängigkeit hochzählen
  5. lsa-server-gsi: release (s.o.)
  6. lsa-server-gsi: rollout
    rollout --dest /common/usr/cscoap/opt
    Rollout of Services and Applications
  7. Info an HKR: keine Eingaben möglich, keine Trims machen während Deployment
  8. Infrastruktur RB Anrufen: LSA Server neustarten
  9. Info an HKR: wieder ok

Debugging von Makerules:
  • lsa-ext-fair-gsi -> lsa-server-gsi -> parammodi-app SNAPSHOT Abhängigkeiten eintragen.
  • lsa.mode=2 und pro Konfig
  • Dann kann man die make rules debuggen
  • Debugger nicht unnötig im Breakpoint stehen lassen da trim lock solange besteht!
DB Änderungen

In der Regel durch: AS, RM, HH
eigentlich nie in der RB, sollte auch nur durchgeführt werden, wenn man sich damit auskennt!
  1. LSA Server stoppen lassen
  2. lsa-db-scripts, lsa-db-pro
  3. LSA Server starten lassen

9.0.1 Hierarchie-/Parameteränderungen

Änderungern an der Hierarchie oder bei Parametern werden idR. tagsüber gemacht! Dazu ist ebenfalls die direkte Absprache mit dem HKR erforderlich oder es wird ein Wartungsfenster benötigt. Dafür auch das common-lsa-utils-uilib-Projekt ausgechecken. Hier werden ggf. neue Oberflächentexte hinzugefügt, die z.B. im Parammodi angezeigt werden.
TIP Falls die Sprachbundles nicht kurz vorher geändert wurden, ggf. beim Modellierer nachfragen. Wenn Sprachelemente nicht geändert werden, muss man solange mit den "kryptischen" Benenennungen auskommen.
Die Modellierer müssen angeben, welche Applikation(en) neu released werden müssen (Parammodi, SchedulingApp).
ALERT! NICHT VERGESSEN: Abhängigkeiten hochziehen!
Mit dem HKR ist immer abzustimmen, wenn die Applikationen neu ausgerollt werden: Vor dem Neustart müssen die alten Applikations-Instanzen vorher beendet werden. Ansonsten können Inkonsistenzen auftreten!
TIP Mit "What'sApp" kann man feststellen, welche der Applikation(en) wo laufen.

9.1. BP_DELETION_ERROR : Failed delete_beamprocess_action

Sollte es beim Versuch, Kontexte zu Löschen, zu Fehlern der folgenden Art kommen:
BP_DELETION_ERROR : Failed delete_beamprocess_action with bp id 73730, Err: ORA-00001: unique constraint (LSA.BP_NAME_UK) violated ORA-06512: at "LSA.SETTINGS_MANAGEMENT", line 1504

So liegt das daran, dass in diesem Kontext ein Beam Prozess enthalten ist, der den gleichen Namen trägt, wie ein anderer Beam Prozess, der am gleichen Tag gelöscht wurde. (Beispiel: Es wurde ein Pattern "ABC" erstellt, gelöscht, ein neues Pattern "ABC" erstellt, gelöscht -> gelöschte Beam Prozesse tragen gleichen Namen). Da Beam Prozesse nicht sofort gelöscht werden, sondern zunächst nur als zu löschend markiert werden, kommt es zu einer Constraint-Verletzung wegen des gleichen Namens. Das sollte normalerweise kein Problem sein, da dem Namen eine Nummer angehängt wird, die hochgezählt wird. Allerdings kann es in seltenen Fällen, wenn sehr viel gelöscht wird, dazu kommen, dass die Nummer überläuft, und dann kommt es doch zu gleichen Namen und Fehlern.

  • kurzfristig: Eventuell reicht, es einfach nochmal zu probieren. Ansonsten zu löschenden Kontext umbenennen und dann löschen. (Vermutlich ausreichend gute Lösung für einen RB-Einsatz!)
  • sauberer: Services-RB rufen und darum bitten, dass der Job zum Löschen der "gelöschten" Beam Prozesse händisch angestoßen wird. (Vermutlich während RB nicht unbedingt notwendig. Der Job läuft normalerweise täglich gegen 8:00 Uhr.)

9.2. Probleme mit BSS und Timing

Bugs in BSS, Data Master, und der Kommunikation zwischen diesen Komponenten bzw. zwischen LSA und diesen Komponenten können dazu führen, dass sich das gesamte System "verklemmt". Das äußert sich z.B. darin, dass das System nicht mehr reagiert (Fehlermeldungen beim Ein- und Ausplanen von Patterns, beim Deaktivieren von Patterns, usw.) oder inkonsistent ist (z.B. scheint ein Pattern gemäß der Infos im BSS Control nicht ausführungsfähig zu sein, an den Events im Snoop Tool erkennt man jedoch, dass es läuft) usw.

9.2.1 Bekannte Ursachen LZMA Decompression Exception / Input Stream Error (Februar 2019)

Der Timing Master wirft u.U. eine Exception, wenn mehrfach hintereinander die gleiche Aktion auf den gleichen Daten ausgeführt wurde. Dies erkennt man daran, dass es im Graylog Exceptions z.B. aus der Scheduling App, BSS Control, dem Request Processor, etc. gibt, die als Cause "Decompression: LZMA reported ERROR DATA" beinhalten.

Die Behandlung erfolgt durch einen Reset des BSS in Zusammenarbeit mit der Timing-RB.

11 Feb 2019 15:02:00,510 Fehler beim Aktualisieren der PatternGroups 
 java.lang.RuntimeException: An error occurred while trying to execute the 'dump' command on the Generator. See diagnostic logging for more information.
 <b>Caused by:</b>
   cern.japc.ParameterException: Decompression:<b> LZMA reported ERROR DATA (1)</b>
 <b>Caused by:</b>
   cern.cmw.rda3.common.exception.ServerException: Decompression:<b> LZMA reported ERROR DATA (1)</b>

Wenn bereits bem Schreiben ein Fehler aufgetreten ist, dann sieht die Meldung etwas anders aus. Die Behandlung ist identisch.
A-Priori Verify for LZMA compression failed, Decompression:<b> LZMA reported ERROR DATA </b>(1)

Am 01.03. wurde die LZMA Library ausgebaut. Am 04.03. trat ein höchstwahrscheinlich verwandter Fehler mit dem Exception-Text "input stream error" auf:

cern.japc.ParameterException: *input stream error* at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
<b> Caused by:</b> 
   cern.cmw.rda3.common.exception.ServerException:<b> input stream error</b> at cern.cmw.rda3.common.util.ExceptionUtils.createRdaServerException(

Es wird vermutet, dass dieser Fehler die eigentliche Ursache ist und auch bereits der Auslöser für die LZMA Exceptions war. Solange die LZMA Library ausgebaut ist, wird statt LZMA Exceptions ggf. dieser Fehler in Logs angezeigt. Die Behandlung ist identisch. "Outdated Context" exception

Kann dazu führen, dass gesamte PatternGroup steht, da "disabled by LSA" Signal gesetzt ist, nachdem Drive fehlgeschlagen ist, weil der mitgesendete Kontext veraltet war (z.B. veraltete Längen, veraltete User/Selektoren, etc.).

Vermeidung: Regelmäßiges Refreshen von Anwendungen, explizites Refresehen nach Kontrollsystem-Reset.

Behebung: Erfolgreiche Versorgung eines Patterns aus der PatternGroup über LSA, z.B. Vollversorgung/Drive aus neugestartetem oder per (Client-)Refresh aktualisiertem ParamModi.

9.2.2 Fehlerbehebung

Vorher: Kontakt zu Services-Rufbereitschaft bzgl. BSS und zu Timing-Rufbereitschaft bzgl. Generator/Data Master. Problem besprechen.
Per Tool

Der Reset kann durch das Tool expert-cs-panic-app (Prototyp!) durchgeführt werden.


Falls Reset durchgeführt werden soll:
  1. Ist-Zustand dokumentieren, um ihn später wiederherstellen zu können (eingeplante Patterns, Unilacanforderungen, gekoppelte Patterns, aktivierte Patterns/Pattern Groups - z.B. Screenshots von Scheduling App oder BSS Control, inkl. Koppel-Dialog im BSS Control).
  2. Im BSS Control z.B. per "Pattern deaktivieren" ALLE Patterns deaktivieren. (Hintergrund: Es könnte sonst sein, dass nach dem Wiedereinplanen einzelne Patterns SOFORT loslaufen, falls das BSS noch veraltete Signal-Infos hat!)
  3. Reset-Vorgang:
    • Falls gekoppelte Patterns vorhanden: BSS Control aus aktuellen Release-Branch auschecken. Im pom.xml Dependency auf die letzte Stable-Version von lsa-server-gsi eintragen. BSS Control aus dem Workspace starten mit den unten angegebenen VM-Parametern. Oben rechts "Patterns koppeln" anwählen und alle entkoppeln.
    • Scheduling App aus aktuellen Release-Branch auschecken. Im pom.xml Dependency auf die letzte Stable-Version von lsa-server-gsi eintragen. Scheduling App aus dem Workspace starten mit den unten angegebenen VM-Parametern. Alle Patterns ausplanen (aus Pattern Groups entfernen und oben rechts Supply/Versorgen klicken).
    • [Parallel: Timing-RB setzt Generator/Data Master zurück, evtl.: Services-RB setzt Request Processor und Director zurück.]
  4. Wenn Schritt 3 vollständig erledigt (auch von anderen RBs):
    • Scheduling App aus dem Pro-Launcher starten. Dort alle gewünschten Patterns wieder einplanen* und oben rechts Supply/Versorgen klicken.
      • * Beim Einplanen ist ggf. zu berücksichtigen, dass bestimmte laufende Experimente z.B. ihren Virtuellen Beschleuniger für den SIS18 (S... im ContextWidget) behalten wollen. Dies kann über die Einplanungsreihenfolge gesteuert werden (es wird immer der nächste freie Virtuelle Beschleuniger genommen). Ggf. beim HKR nachfragen. Notfalls alle Patterns einzeln nacheinander einplanen, in der Reihenfolge der angegeben Virtuellen Beschleuniger für SIS (S..) und ESR (E..) (beide nutzen den gleichen Zahlrenraum).
    • BSS Control aus dem Pro-Launcher starten. Dort Kopplungen wiederherstellen. Ggf. in Schritt 2 deaktivierte Patterns wieder aktivieren.
  5. Client-Refresh in allen offenen ParamModi-Anwendungen (sonst steht LSA evtl. nach nächster Versorgung! siehe OutdatedContextException), am besten auch SchedulingApps neustarten.

Die Schritte 4 und 5 können ggf. auch von den Operateuren durchgeführt werden, das muss nicht durch uns geschehen.

Zu verwendende VM-Parameter:

Die Programme können auch entsprechend konfiguriert gestartet werden:
webstart --quiet --config=pro --vmargs="-Dlsa.mode=2 -Dlsa.bss.generator.dataSupplyEnabled=false -Dlsa.bss.director.dataSupplyEnabled=false -Dlsa.bss.requestProcessor.dataSupplyEnabled=false"

webstart --quiet --config=pro --vmargs="-Dlsa.mode=2 -Dlsa.bss.generator.dataSupplyEnabled=false -Dlsa.bss.director.dataSupplyEnabled=false -Dlsa.bss.requestProcessor.dataSupplyEnabled=false"

Sollte das Programm auf diese Weise Fehler werfen (z.B. veraltete MakeRules) muss auf den aktuellen Release-Branch zurückgegriffen werden und per Eclipse oder mvn exec:java -D... gestartet werden.

10. Quellenprogramm

Beim Fortran-(!) Quellenprogramm muss u.U. auf eine frühere Version zurückgegriffen werden. Dafür muss die RB von Betriebssoftware UNILAC wissen, wo die vorher verwendete Version liegt. Im Acc-6 Cluster im Verzeichnis /common/usr/cscosv/bin-repos/op-aps/iq-co/write/dflt-i386 befinden sich alle vorhandenen Vorgängerversionen, der Link develop zeigt auf die aktuelle Version. (Wenn man auf eine vorhergehende Version zurückgehen will, muss man den Link develop ändern. Gestartet wird ausschliesslich von den Kollegen RB von Betriebssoftware UNILAC).
Die derzeitige Rückfallversion ist die vom Juli 2016.

11. HowTo

11.1 Rollout

Falls eine neue SW-Version ausgerollt werden muss, ist das vorher mit dem Schichtleiter im HKR abzustimmen. Sollte ein Ausrollen bis zur nächsten Mittagssitzung nicht möglich sein, bitte ein kurze Info an Regine. Sie wird das dann bei der täglichen Mittagssitzung vorbringen, damit ein geeigneter Zeitpunkt dafü festgelegt werden kann. Sollten dann immer noch nicht alle erreicht worden sein, die darüber Bescheid wissen müssten, werden diese per Email informiert.

11.2 "Vollversorgung"

Eine "Vollversorgung" aus der Scheduling App heißt: Alle Patterns einer Pattern Group (oder sogar alle Patterns in allen Pattern Groups) ausplanen, versorgen ("Versorgen / Supply" oben rechts), gewünschte Patterns wieder einplanen, versorgen. Ob eine oder mehrere Pattern Groups betroffen sind, muss der RBler einschätzen (wenn z.B. 2 von 3 Pattern Groups fehlerfrei arbeiten, sollte man zunächst versuchen, nur die eine fehlerhafte neu zu versorgen, etc.).

Eine "Vollversorgung" in Bezug auf Geräte / LSA-Settings findet aus ParamModi statt: Kontext auswählen, unten bei "An Geräte schicken" stattdessen über Dropdown "Ganzen Kontext schicken" wählen. Mehrere Kontexte ggf. nacheinander abarbeiten (kann z.B. notwendig sein, wenn ein Gerät neu zugeschaltet oder resettet wurde - dann müssen alle Kontexte, in denen dieses Gerät Settings haben kann, neu versorgt werden.)


-- JuttaFitzek - 16 Aug 2017

Topic revision: r62 - 07 May 2020, JuttaFitzek
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback