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. Organisatoric and General information regarding On-call duty

On-call duty in general

• Handout On-call duty (GSI)
• [[Timing/Intern/TimingSystemArbeitszeitUndRufbereitschaft][Work hours and On-call duty (Timing Wiki)]
• Overview, whom to call (ACO)
• Telephone numbers (Control rooms, etc.)

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 "Morning Briefing" (8.30Uhr, Zoom) and be ready to report about APP OLOG entries. In case you cannot participate, organize an APP colleague that can attend instead.
• Visit the "Mittagssitzung" (12:45Uhr, Zoom) and be ready to report about APP OLOG entries. In case you cannot participate, organize an APP colleague that can attend instead.
• Visit "OCM Meeting" on Wednesdays (9:00Uhr, Zoom) if neither JF nor AW is going, be ready to report on issues listed in the Technical Defect Report (OLog Login required).
  (If nobody is there/ has time, talk to Regine Pfeil or HH and report in detail about APP issues so that they can report on the status instead)

HowTo

Dienste / Services

• Icinga -> https://monitoring-acoapp.acc.gsi.de/icinga/monitoring/list/servicegrid?flipped=1
• Existierende Dienste, URLs, Ports und deren Konfigurationen: ApServiceLocationDefinitions
• Fehleranalyse
  • logging nach Fehler durchsuchen -> https://logging.acc.gsi.de -> login as anonymous
  • asl15* -> bob -> heapdump -> AppOnCallDutyMain#Heap_Dump_erstellen
  • asl15* -> bob -> journalctl --user -u lsa-server-gsi -b 0
• Pro Dienste werden von systemd verwaltet und laufen als Benutzer bob auf asl156.acc.gsi.de
  • Eine Dokumentation des setups und der wichtigsten Befehle von INN: https://git.acc.gsi.de/handel/bob-services/src/branch/master/bob.md#systemd
  • Rollout von Diensten mit Ansible, Neustart sollte dann automatisch erfolgen!
    • Siehe zur Absprache AppOnCallDutyMain#Rollout
    • Manueller Restart: asl15* -> bob -> status / ggf restart

Rollout

Falls eine neue SW-Version ausgerollt werden muss, ist das vorher mit dem Schichtleiter im HKR abzustimmen. Sollte ein Ausrollen bis zum nächsten Betriebsmeeting (Morning Briefing oder Mittagssitzung) nicht möglich sein, bitte im entsprechenden nächsten Betriebsmeeting vorbringen, damit ein geeigneter Zeitpunkt dafür festgelegt werden kann. Sollten dann immer noch nicht alle erreicht worden sein, die darüber Bescheid wissen müssten, werden diese per Email informiert.

Für den Rollout auf PRO verwenden wir Ansible:

https://git.acc.gsi.de/fcc-commons/acoapp-ansible#usage

Problem solving using the "Panic" App

expert-cs-panic-app is an application to reset the state of several central services and resupply them with the required data. Basically "resetting" the whole control system to a defined state.

Before: If you assume that the problem is timing related, please contact the Timing-On-Call-Duty to secure state and logs for later diagnostic.

The reset can be done using expert-cs-panic-app (ACO-APP Expertenprogramm), documentation is on the GIT front page..

"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.)

Diagnose bei OutOfMemory-Errors

Wenn bei einer Anwendung Fehlerverhalten auftritt (hängt, zeigt falsche Infos an, ...), bei dem man den Verdacht hat, dass ein vollgelaufener Speicher der Grund sein könnte oder man den Anwendungszustand genau analysieren möchte, dann kann ein Heapdump nützlich sein.

Wenn möglich: Heapdump erzeugen und zukommen lassen. Falls das Problem im HKR auftrat und man selbst nicht vor Ort sein kann, je nach HKR-Besetzung die folgenden Schritte durchführen lassen.

Prozess-ID ermitteln

Zum Beispiel durch eine der beiden Alternativen:

Mit Hilfe von Logging-System (s.u.) oder durch den Operateur über das terminal auf der Konsole: jps und nach dem Programmnamen schauen. Beispiel:

jps
2529 DigitizerExpertApp
28707 Jps
486 LauncherApp

Bei der DigitizerExpertApp wäre dies die PID 2529.

Heap Dump erstellen

jmap -dump:live,format=b,file=<filename>.hprof <PID>

Zum Beispiel: jmap -dump:live,format=b,file=/tmp/dump_digitizer_expert_app_tcl1030.hprof 2529

Dump auf den Cluster bringen (benötigt Cluster-Account):

scp /path/to/<dump-filename> <username>@asl75<n>:/tmp

(n ist dabei die gewünschte asl Instanz. Bei dem Verzeichnis /tmp muss auch auf der passenden asl nach der Datei geschaut werden. Statt /tmp kann auch z.B. /scratch/dump verwendet werden.)

Zum Beispiel: scp /tmp/dump_digitizer_expert_app_tcl1030.hprof awalter@asl754:/tmp

Es kann sein, dass noch der Dateizugriff durch den Operateur gewährt werden muss:

ssh <username>@asl75<n>
chmod a+rw <filename>

Die Dump-Datei dann bitte aus dem /tmp oder /scratch Verzeichnis z.B. ins eigene Home-Verzeichnis umziehen, damit sie nicht automatisch gelöscht werden kann. Nach erfolgter Analyse kann die Datei dann gelöscht werden.

Analyse z.B. mit jvisualvm , Eclipse Memory Analyzer, …

Nachvollziehen der Fehler im Logging-System

Häufig werden OOMs von unserem Uncaught-Exception-Handler erwischt. Praktische Suchen sind z.B. (ggf. mit Einschränkung auf StackTrace-Feld):

OutOfMemory

java.lang.OutOfMemoryError

StackTrace:*OutOfMemory

"heap space"

Diagnose hängender Anwendungen

Analog zum Heapdump kann ein Thread-Dump einen guten Überblick über den Stand der Anwendung geben. Ein Abzug kann mit folgendem Befehl gemacht werden.

jstack PID  > /tmp/thread-dump-example-app_tcl1030.txt

PID Ermittlung und Dateitransfer wie oben in Abschnitt 11.3 zur „Diagnose bei OutOfMemory-Errors“.