Monitoring ohne Umwege

Alle meine Prozesse

Ein wichtiger Aspekt der Administration ist die Beobachtung der auf dem System laufenden Prozesse, vor allem, wenn ein einzelnes Programm sich anders verhält als erwartet. Statt mühselig verschiedene Prozess-Monitore zu starten und in einer endlos langen Liste nach Ihrem Problemkind zu suchen, bedienen Sie sich einfach der Informationen unter /proc. Prozessinformationen befinden sich in den Unterverzeichnissen, deren Name aus einer Nummer besteht. Die Nummern der Unterverzeichnisse sind mit den PIDsder laufenden Programme identisch. Ein in einem Prozess ablaufendes Programm kann mehrere parallel ablaufende Kind-Prozesse erzeugen. Nur als Superuser root haben Sie Zugriff auf alle Prozessverzeichnisse. Sind Sie als Benutzer unterwegs, sind einige Informationen über Prozesse, die anderen Nutzern gehören, für Sie tabu. Um Daten zu einem bestimmten Programm zu erhalten, bringen Sie die Prozess-ID mittels

ps -e | grep Programmname

in Erfahrung.

Mit diesem Kommando wird zunächst eine vollständige Prozessliste angefordert, die Ausgabe jedoch nicht angezeigt, sondern mittels einer Pipe(|) an den Befehl grep weitergereicht. Die Ausgabe zeigt dann nur jene Prozesse an, in denen grep das angegebene Schlüsselwort, den Programmnamen, findet.

Infos über ein laufendes aterm werden prompt geliefert:

[andi@gemini andi]$ ps -e | grep aterm
1242 pts/0    00:00:00 aterm

Die Zahl 1242 ist die Prozess-ID des Programmes. Wechseln Sie nun in das entsprechende Prozessverzeichnis unter /proc und verschaffen Sie sich mit ls -l einen Überblick (Listing 1).

[andi@gemini 1242]$ ls -l
-r--r--r--    1 andi     andi            0 Okt 13 01:05 cmdline
lrwxrwxrwx    1 andi     andi            0 Okt 13 01:05 cwd -> /home/andi/
-r——–    1 andi     andi            0 Okt 13 01:05 environ
lrwxrwxrwx    1 andi     andi            0 Okt 13 01:05 exe -> /usr/bin/aterm*
dr-x——    2 andi     andi            0 Okt 13 01:05 fd/
-r--r--r--    1 andi     andi            0 Okt 13 01:05 maps
-rw——-    1 andi     andi            0 Okt 13 01:05 mem
lrwxrwxrwx    1 andi     andi            0 Okt 13 01:05 root -> //
-r--r--r--    1 andi     andi            0 Okt 13 01:05 stat
-r--r--r--    1 andi     andi            0 Okt 13 01:05 statm
-r--r--r--    1 andi     andi            0 Okt 13 01:05 status

Die beiden Links cwd und exe zeigen auf das aktuelle Arbeitsverzeichnis des Prozesses und den Speicherort der Programmdatei. Der Link root zeigt auf das von dem Programm benutzte Wurzelverzeichnis, in der Regel also /. Anders sieht es aus, wenn Sie einen Dienst aus Sicherheitsgründen in einer chroot-Umgebung laufen lassen. Haben Sie den Dienst entsprechend konfiguriert, überprüfen Sie mit

ls -l /proc/$PID/root

ob Sie den Server erfolgreich eingesperrt haben.

Einige Programme verhalten sich unterschiedlich – je nachdem, ob sie über einen Eintrag im Menü des Window Managers oder aus einem per Kommandozeilenaufruf gestartet werden. In den meisten Fällen liegt das daran, dass die von Ihrem Distributor erstellten Menüs dem Programm zusätzliche Parameter beim Aufruf mitgeben. Ein Blick in /proc/$PID/cmdline hilft, den exakten Aufruf zu ermitteln:

[andi@gemini 1242]$ cat cmdline
aterm-tr-trsb-fn-misc-fixed-medium-r-normal-*-*-140-*-*-c-*-iso8859-15

Leider ist die Ausgabe nicht formatiert, und Sie müssten raten, wo bei diesem Programmaufruf die Leerstellen für die Optionen zu setzen sind. Der Grund dafür ist, dass in einigen der Dateien unter /proc binäre Zeichen vorkommen. Die einzelnen Parameter des Programmaufrufs sind in der Ausgabe durch binäre Nullen getrennt, weshalb es sich zur besseren Lesbarkeit anbietet, die Ausgabe von cat mittels einer Pipe an das Programm trzu schicken.

Nach dem tr-Aufruf erhalten Sie also mit

[andi@gemini 1242]$ cat cmdline | tr "\000" " "
aterm -tr -trsb -fn -misc-fixed-medium-r-normal-*-*-140-*-*-c-*-iso8859-15

eine leserlich formatierte Ausgabe. Mit diesem Wissen ist es ein Leichtes, die Menüs anderer Window Manager anzupassen oder einen Aliasmit dem entsprechenden Aufruf für die Shell zu definieren.

Ähnlich hilfreich ist oft ein Auslesen der /proc/$PID/environ-Datei, in welcher alle für das Programm gesetzten Umgebungsvariablen stehen. Allerdings beinhaltet auch diese Datei binäre Nullen, die Sie der Übersicht halber nicht durch Leerstellen, sondern durch Zeilenumbrüche ersetzen sollten. Um alle gesetzten Umgebungsvariablen im Blick zu haben, schicken Sie die Ausgabe des tr-Befehls nicht direkt an die Standardausgabe, also den Bildschirm, sondern an den Pager less. Das "\n" steht für "newline" und sorgt für den entsprechenden Umbruch. Der Aufruf

cat environ | tr "\000" "\n" | less

formatiert die Ausgabe lesbar (Abbildung 1).

Abbildung 1: Aus /proc ausgelesene Umgebungsvariablen eines Prozesses

Die Wurzel allen Übels

Die Ausführung von KDE-Programmen führt mitunter zu seltsamen Fehlern, wenn die Variable QTDIR nicht richtig oder gar nicht gesetzt ist. Das passiert beispielsweise dann, wenn aus Kompatibilitätsgründen verschiedene QT-Versionen installiert sind und die KDE-Programme auf die falsche Version zugreifen – entweder, weil sie weiter vorne im Pfad liegt als die benötigte Version, oder weil der Benutzer die Variable falsch gesetzt hat. Bevor man also einen Programmfehler vermutet und dem Autor einen Bug-Report schickt, lohnt es sich, zunächst einmal die gesetzten Variablen zu überprüfen.

Auch wenn sich ein Benutzer über fehlende deutschsprachige Oberflächen beklagt, liegt das nicht immer an einer unvollständigen Installation der Lokalisierungs-Dateien oder der Systemkonfiguration. Vielleicht besteht das Problem in falsch gesetzten LANG- und LC-Variablen. Diese können über Konfigurationsdateien eines Programmes gesetzt werden, oder der Benutzer hat sie unwissentlich selbst gesetzt, als er die Startdateien seiner Shell anpassen wollte.

Verhält sich ein auf Ihrem System laufender Dienst nicht wie erwartet, hilft oft ein Blick in das entsprechende Logfile bei der Lösung des Problems. Da die laufenden Dienste in der Regel von Ihrem Distributor vorkonfiguriert wurden, müssen Sie sich nun auf die Suche nach der fraglichen Datei begeben. Da ein manuelles Durchsuchen des /var/log-Verzeichnisses mühsam ist, bedienen Sich sich auch hier der unter /proc liegenden Informationen. Nach Ermittlung der Prozess-ID gehen Sie folgendermaßen vor:

[root@gemini test]# ls -l /proc/978/fd
total 0
lr-x——    1 root     root           64 Okt 15 13:34 0 -> /dev/null
l-wx——    1 root     root           64 Okt 15 13:34 1 -> /dev/null
[…]
l-wx——    1 root     root           64 Okt 15 13:34 2 -> /var/log/httpd/error_log

Das Unterverzeichnis fd beinhaltet alle von einem Prozess geöffneten Dateideskriptoren. Dabei handelt es sich um Verknüpfungen, die auf den Speicherort der geöffneten Dateien verweisen. Die Dateideskriptoren 0 bis 2 repräsentieren die Dateiobjekte Standardeingabe, Standardausgabe und Fehlerausgabe (stdin, stdout und stderr). Im obigen Beispiel wird die Fehlerausgabe, also Deskriptor Nummer 2, des Prozesses nach /var/log/httpd/error_log geschrieben.

Jetzt wissen Sie auch, weshalb es unklug ist, zu große Log-Dateien händisch zu löschen, statt diese Aufgabe einem Programm wie logrotate zu überlassen. Entfernen Sie beispielsweise die Datei error_log, ist der auf die Datei verweisende Dateideskriptor noch immer geöffnet und wird zu Protokollierung der Aktivitäten des Dienstes verwendet. Da die Datei nicht mehr vorhanden ist, landen die Log-Einträge im Nirvana.