Devman unter Linux administrieren und warten

ACHTUNG, Inhalt ist alt und muss für acc6/acc7 grundlegend überarbeitet werden!

---

---

Service DevMan

Der DevMan ist auf den PowerPC-Boards als Service eingerichtet.

Handhabung als root über Befehl 'service'

  service devman {start|stop|restart|status}

Mit 'service devman' passiert nix schlimmes, es wird eine Liste der unterstützten Kommandos ausgegeben.

Das eigentliche Startscript liegt hier

  /etc/rc.d/init.d/devman

Um sicher zu stellen, dass der per service devman gestartete DevMan nur einmal läuft, wird beim Start ein File mit der jeweiligen Prozess-Id angelegt

  /var/run/devman.pid

sowie ein Lock-File (siehe weiter unten: Probleme bei Start/Restart)

  /var/lock/acc/devman

Diese pid wird auch beim Stop des Services gebraucht, da das Init-Skript bei Stop nicht einfach killall devman sagen und dabei alle devman abräumen kann.

Erste Diagnosemöglichkeit ist das Kommando

  service devman status

Dieses zeigt an, ob der DevMan läuft, mit Liste der Process-Ids. Unter dem Kernel 2.6 sieht die Ausgabe nun etwa wie folgt aus:

  -bash-3.2# service devman status
  devman (pid 498) is running...
    PID   LWP TTY          TIME CMD
    498   498 ttyp1    00:00:01 devman
    498   500 ttyp1    00:00:00 devman
    498   501 ttyp1    00:00:00 devman
    498   503 ttyp1    00:00:00 devman
    498   519 ttyp1    00:00:00 devman
    498   522 ttyp1    00:00:00 devman
    498   523 ttyp1    00:00:00 devman
    498   524 ttyp1    00:00:00 devman

Dabei ist im Beispiel der Prozess mit der PID 498 der Hauptprozess. Alle anderen Prozesse mit PID ungleich LWP sind Light Weight Processes, also die von Devman gestarteten Threads.

Erscheint als Status-Meldung stopped, so wurde der DevMan (wahrscheinlich) ordnungsgemäß beendet, während die Meldung dead, but pid-file exists stark darauf hindeutet, dass er abgestürzt ist.

Geht ein Restart schief

  -bash-3.2# service devman restart
  Stopping devman                                            [  OK  ]
  Starting devman                                            [FAILED]

kann das u.a. daran liegen, dass das Lockfile noch existiert. Das kann man anhand des Logfile herausbekommen:

  -bash-3.2# tail -30 /var/log/equ/debug
  ...
  Feb  5 11:22:16 ke3cg08 devman: lockfile-linux.cc::createLockfile:26: 
  Lockfile /var/lock/acc/devman is already existing! Devman not started.
  ...
  -bash-3.2# rm -f /var/lock/acc/devman
  -bash-3.2# 

Das Lockfile muss dann manuell gelöscht werden.

In seltenen Fällen kann der Service "Starting devman [ ok ]" melden, obwohl der Devman nicht gestartet werden konnte. Das passiert in den Fällen, wo Devman in der Startphase abstürzt und einen core dump schreibt. Das dauert länger als 5s. Der service guckt aber nach 5s, ob der gestartete Devman noch läuft. Tut er das - und in unserem Fall ist er ja noch mit dem core dump beschäftigt -, dann meldet der Service [ ok ]. Mehr dazu findet man unter Devman Core Dump debuggen.

Ein weiterer Grund, dass Devman nicht startet, kann eine nicht gefundene Bibliothek sein. Auch das kann man anhand des Logfile herausbekommen:

  -bash-3.2# tail -30 /var/log/equ/debug
  ...
  Feb  5 10:41:32 ke3cg08 DevMan[453]: devman.cc::DeviceManager:446:
  Couldn't load shared object mx.so
  ...
  ./devman: error while loading shared libraries: libnsrvtcpip.so.9.8: 
  cannot open shared object file: No such file or directory
  -bash-3.2# 

Oft hilft dann schon ein

  -bash-3.2# ldconfig
  -bash-3.2# service devman start
  Starting devman                                            [  OK  ]

Außerdem müssen die Links unter /opt/acc/cpu auf eine gültige Release des DevMan und gültige USRs zeigen.

  -bash-3.2# ll
  total 104
  ...
  lrwxrwxrwx    1 hechler  bel            31 Jan 10 11:17 library -> /opt/acc/sys/devman/14
  lrwxrwxrwx    1 hechler  bel            30 Dec  4 10:08 ec.so -> /opt/acc/eqp/ec/ec.so.14.09.12.04
  ...
  lrwxrwxrwx    1 hechler  bel            30 Dec  4 10:12 md.so -> /opt/acc/eqp/md/md.so.10.09.10.06

Gebrochene Links, die auf eine nicht existierende Datei zeigen, blinken üblicherweise rot. Dann kann eventuell ein Release der entsprechenden Datei helfen.

  asl721> reldevman kp1cg02 14
  asl721> relusrs -gup=kp1cg02 md 09.10.06

Es gibt aber auch Meldungen, die auf der Konsole, also dem Bildschirm, ausgegeben werden, wenn der Devman interaktiv gestartet wurde. Diese Ausgaben landen beim Start des Devman via service in der Datei

  /var/log/equ/devman.console

die bei jedem Start des Devman neu angelegt wird. Die letzten fünf Dateien werden allerdings aufgehoben. Sie heißen

  /var/log/equ/devman.console.1
  ...
  /var/log/equ/devman.console.5

#Message-Queue voll

Message-Queue

Mit ipcs (InterProcessCommunicationStatus) kann man feststellen, wie der Status der Message-Queue ist. Es gab schon Fälle, in denen die Alarm-Message-Queue (in der folgenden Tabelle key 0x00002694) vollgelaufen war und deshalb der devman nicht mehr neu gestartet werden konnte.

-bash-3.2# ipcs

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages
0x00001267 0          root       666        0            0
0x00000929 32769      root       666        0            0
0x00002694 65538      root       666        16368        186

In diesem Fall hilft ein Löschen der Queue vor dem devman Neustart.

-bash-3.2# service devman stop
-bash-3.2# ipcrm -q 65538
-bash-3.2# service devman start

Ab Release 18 sollte das nicht mehr nötig sein.

Gerätekonfiguration: Datenbasis

Der Devman erwartet in seinem Directory '/opt/acc/cpu/' ein Datenbasis-File, in dem die Gerätekonfiguration definiert ist (Nomenklaturen, Adressen, Gerätemodelle und Gerätekonstanten).

Dieses Datenbasis-File (z.B. kp1cg02.dbs) ist über die utility 'dbsgen' zu erstellen und kann mit dbscopy auf das CPU-Directory kopiert werden.

  $ dbsgen kp1cg02
  $ dbscopy kp1cg02

Siehe dazu auch Verzeichnisse @ asl.

Verzeichnisse @ PPC

Für die Kontrollsystem-SW sind drei Directories von Bedeutung (alle Pfade aus Sicht der PowerPCs, d.h eingelogged darauf)

/opt/acc/sys/

für alle PowerPCs gemeinsames Directory mit der System-Software

/opt/acc/eqp/

für alle PowerPCs gemeinsames Directory, enthält in Unterdirectories jeweils alle Versionen der Geräte-SW für ein Gerätemodell. Geräte-SW liegt dort als shared Libraries, etwa

• /opt/acc/eqp/md/md.so.14.09.10.05
• /opt/acc/eqp/md/md.so.14.09.10.06

/opt/acc/cpu/

spezifisch für jeden PowerPC (jeder GµP hat sein eigenes Directory) enthält, unter anderem,

• Datenbasis, als File <Rechnername>.dbs
• für jede Gerätesoftware einen (Soft-)Link <Gerätemodell>.so, der auf die jeweils zu ladenden USRs zeigt (Version beachten!)
  Also z.B. für Rechner KTRCG07 die Datenbasis und zwei Links auf USRs (md für Magnete und ec für die ECM-Properties):
  • ktrcg07.dbs
  • ec.so -> /opt/acc/eqp/ec/ec.so.14.09.06.01
  • md.so -> /opt/acc/eqp/md/md.so.14.09.10.06

Verzeichnisse @ asl

Alle Directories der PowerPCs sind vom Filesystem des asl-Clusters gemountet. Daher sind diese Directories auch von den asl-Rechnern (asl720, ...) aus zu erreichen. Sie sind im asl-Cluster zu finden unter

/common/usr/eldk/

Im Einzelnen:

Die für alle PowerPCs gleichen Directories

• /opt/acc/eqp/
• /opt/acc/sys/

sind im asl-Cluster zu erreichen als

• /common/usr/eldk/ppc_6xx/opt/acc/eqp/
• /common/usr/eldk/ppc_6xx/opt/acc/sys/

Die PowerPC-spezifischen Directories liegen im asl-Cluster unter

• /common/usr/eldk/<Rechnername>/

Etwa für den KTRCG07 ist das aufgeführte rechner-spezifische Directory mit der SW-Konfiguration im asl-Cluster zu finden als

• /common/usr/eldk/ktrcg07/opt/acc/cpu/

Auf die CPU-Directories kommt man auch mit

• > cdcpu ktrcg04
• > cdcpu ktrcs042

Logfiles

Die GuPs nutzen den zentralen Syslog-Server zum Loggen. Deshalb können die Logfiles nur von den Blades (asl72x, asl32x) aus eingesehen werden. Die GuP-spezifischen Logs sowohl der VME-GuPs als auch der uIOC-GuPs liegen in

  /common/log01/logs/<GuP-Name>

und sind ganz einfach zu erreichen mit

  $ cdlog <GuP-Name>

Auf der Directory gibt es fünf verschiedene Files:

• devman-debug.<yyyy-mm-dd>.log
• devman-info.<yyyy-mm-dd>.log
• devman-err.<yyyy-mm-dd>.log
• kern.<yyyy-mm-dd>log
• messages.<yyyy-mm-dd>.log

In devman.debug.<yyyy-mm-dd>.log landen alle Log-Meldungen des Devman.
In devman.info.<yyyy-mm-dd>.log landen alle Log-Meldungen des Devman außer Debug-Meldungen.
In devman.err.<yyyy-mm-dd>.log landen alle Log-Meldungen des Devman außer Debug-, Info- und Warning-Meldungen.
In kern.<yyyy-mm-dd>.log und messages.<yyyy-mm-dd>.log landen keine Meldungen vom Devman, sondern nur welche von Linux selbst.

Logfiles, die älter als eine Woche sind, werden gezippt und heißen dann z.B. devman.debug.<yyyy-mm-dd>.log.gz. In diesen kann man übrigens einfach mit zgrep suchen, z.B.:

  $ zgrep TK1MU1 devman-debug.2012-01-24.log.gz

Zum Testen des Logging-Mechanismus kann man das Programm logger verwenden. Hierzu gibt man, nach Einloggen auf dem PowerPC, z.B. folgendes Kommando ein:

  $ logger -p local0.info "Meine Testmeldung im Log-File"

Hierbei ist local0 der Kanal für benutzerdefinierte Meldungen, wie er auch vom Devman verwendet wird. In local0.<stufe> erlaubte Stufen der Fehlermeldungen sind err, info und debug.

Sollwert-Logging

Ab Release 21 werden auch Sollwert-Zugriffe geloggt. Jeder Zugriff auf eine Write- oder Call-Property wird in der Datei

  /common/log01/logs/<GuP-Name>/devman-devacc.<yyyy-mm-dd>.log

festgehalten. Geloggt werden Nomenklatur, Property-Name, VrtAcc, die ersten maximal fünf Parameter, die ersten maximal fünf Daten, sowie Informationen über User, Process und Host. Ein Eintrag sieht etwa so aus:

  Jan 26 13:08:28 kp1cg01 info DevMan[1491]: DEVACC: TK1MU1, CURRENTS, vrtacc = 1, data[0] = 1.234, 
    by user 'hechler', uid 609, process 'simple', pid 25859, lwp 25859, proc desc '(none)' at asl723.acc.gsi.de

Da für Zugriffe von VMS aus über Userface/UfcServer der (Linux-) User immer belsvc und der Process immer der UfcServer ist, steckt in der Prozessbeschreibung (proc desc) die ursprüngliche User-, Process- und Host-Information von VMS:

  Jan 26 09:10:02 k4xcg03 info DevMan[2095]: DEVACC: IPSBOX04, DISPLAY, vrtacc = 0, 
    para[0:4] = 0, 0, 4269913484, 608255492, 1, data[0:4] = T, K, 9, Q, D, 
    by user 'belsvc', uid 637, process '21931', pid 21931, lwp 21931, 
    proc desc 'SISKONS, prc TKPOTI on axp343.acc.gsi.de' at asl320.acc.gsi.de

Auch hier werden Logfiles, die älter als eine Woche sind, gezippt. Sie heißen dann entsprechend devman.devacc.<yyyy-mm-dd>.log.gz.

DevMan beim Booten starten

Beim Booten durchläuft ein Linux-System alle im Verzeichnis /etc/rc.d/rcX.d verlinkten Skripte nach folgenden Schema, wobei X dem Default-Runlevel des Systems entspricht (dies ist bei Systemen mit X-Windows 5, bei Systemen - PPC - ohne X-Windows 3). Hierbei beginnen die Links entweder mit Kxx oder Sxx. Zuerst werden alle Services beendet, die in diesem Runlevel nicht laufen dürfen, in dem alle als Kxx verlinkten Skripte mit dem Parameter stop aufgerufen werden. Dies erfolgt in der Reihenfolge der Zahlen xx, also kommt K01pumuckl vor K99heinz. Dann werden alle Services gestartet, die in diesem Runlevel laufen sollen, indem die als Sxx... verlinkten Skripte mit dem Parameter start aufgerufen werden, wieder anhand der Reihenfolge, die sich durch xx ergibt.

Für ppc ist rc3.d entscheidend, ebenso wie rc6.d (Runlevel für reboot) und rc0.d (Runlevel für halt).

Im Allgemeinen gibt es in rc3.d den Link

S99devman -> ../init.d/devman

und ind rc0.d und rc6.d den Link

K01devman -> ../init.d/devman

(Heißt, beim reboot wird der devman direkt zu Anfang beendet, beim Booten ganz am Ende gestartet).

Die Links in rc0.d und rc6.d sollen so sein, und es gibt keinen Grund, sie zu ändern.

Möchte man, dass beim Booten der DevMan gestartet wird, muss man also schauen, dass in rc3.d der Link S99devman existiert, K01devman aber nicht. Soll DevMan nicht automatisch gestartet werden, muss K01devman existieren, S00devman aber nicht.

DevMan interaktiv starten

Der DevMan kann unter Linux interaktiv mit verschiedenen Startoptionen gestartet werden. Es koennen entweder die sog. short options (z.B. -f <dbsfile> -p -d) oder die sog. long options (z.B. --dbsfile=<dbsfile> --persistent --debug) verwendet werden.

-f <dbsfile>, --dbsfile=<dbsfile>

Name des DBS-Files (ohne Endung .dbs)

-p, --persistent

persistente Corba-IORs verwenden (default)

-t, --transient

Corba-IOR wird transient; fehlt diese Option: persistent

-e port, --endpoint=<port>

Port-Nummer für den ORB-Endpoint (nur im persistent IOR mode)

-d, --debug

das Loglevel wird auf LOG_DEBUG gesetzt

-w, --warning

das Loglevel wird auf LOG_WARNING gesetzt

-i, --info

das Loglevel wird auf LOG_INFO gesetzt

-c, -corbans

CORBA-Nameservice verwenden, sonst GSI-Nameservice

Das ist z.B. wichtig, wenn man auf einem asl-Rechner mehrere Device Manager parallel laufen lassen möchte. In diesem Fall muss nun immer die Option -t benutzt werden.

Wie er gestartet wurde, kann man am Output im logfile unter /var/log/equ/ erkennen. Beispiel:

  ./devman -f dbsname -t
  devman starting as dbsname (IOR transient)
  ...

  ./devman --dbsfile=sepp
  devman starting as SEPP (IOR persistent)
  ...

Beim interaktiven Start muss die Umgebungsvariable ACC_NAMESERVER_HOST gesetzt sein, damit Devman den Nameserver findet.

  export ACC_NAMESERVER_HOST=asl721.acc.gsi.de

Konfigurationsdateien

Die zum Starten des Devman notwendigen Konfigurationsdateien sind im Projekt devman/ppc_6xx abgelegt.
Achtung: Einzelne Dateien haben im Repository einen anderen Namen als im Produktionsverzeichnis.

• devman.logrotate
  • Produktionsname: devman.logrotate
  • Produktionsverzeichnis: [$UROOT/eldk/<GuP>]/etc/sysconfig
• devman.service
  • Produktionsname: devman
  • Produktionsverzeichnis: [$UROOT/eldk/<GuP>]/rc.d/init.d
• devman.sysconfig
  • Produktionsname: devman
  • Produktionsverzeichnis: [$UROOT/eldk/<GuP>]/sysconfig
• ec-irpts-load.sh
  • Produktionsname: ec-irpts-load.sh
  • Produktionsverzeichnis: [$UROOT/eldk/ppc_6xx]/home/vme/interrupt
• Makefile.devman
  • Installiert die Dateien devman.* in das Produktionsverzeichnisse des GuPs.
• Makefile.ec-irpts
  • Installiert die Datei ec-irpts-load.sh in das Produktionsverzeichnis.

Weitere Tipps

• Siehe die Tipps für den PPC-GuP in den Tipps für die Rufbereitschaft.