Es gibt unter Linux mehrere Dutzend Programme, die Sie über das System, die laufenden Prozesse und die verwendete Hardware informieren. Einen nur wenig beachteten und direkten Weg zu den gewünschten Auskünften zeigt dieser Artikel.

Was tun, wenn sich ein Programm nicht so verhält wie gewünscht oder erwartet? Wenn Sie Ihrem Linux-Rechner klarmachen wollen, dass er Port Forwardingzu leisten hat? Oder wenn Sie wissen möchten, ob Ihr Kernel in der Lage ist, NTFS-Partitionen zu mounten? Normalerweise fangen Sie jetzt an, Monitoring-Programme zu bemühen. Sie klicken sich durch die Konfigurations-Interfaces Ihres Distributors und lesen seitenweise Dokumentation. Manchmal lässt sich diese Vorgehensweise jedoch abkürzen, wenn man den effektiven Weg über das /proc-Dateisystem kennt.

Mehr als nur ein Verzeichnis

Der erste Blick in das /proc-Verzeichnis bedeutet meist eine Schrecksekunde für den frischgebackenen Linux-Administrator, findet sich doch nach einem prüfenden ls -l unter anderem folgendes:

-r——–    1 root     root     402657280 Okt 13 00:35 kcore

Sollte da wirklich eine Datei mehrere hundert Megabyte Plattenplatz verbrauchen? Des Rätsels Lösung ist einfach: Es handelt sich bei der Datei kcore um ein Abbild des in den Rechner eingebauten Arbeitspeichers. Anders als die ls -l-Ausgabe vermuten lässt, benötigt die Datei keinen Festplattenplatz, da es sich bei dem /proc-Verzeichnis um ein virtuelles Dateisystem handelt, welches für den Benutzer eine einfache Schnittstelle zu Verwaltungsinformationen des Kernels bereitstellt. Die Ausgabe des Befehls mount zeigt, dass es sich bei dem /proc-Verzeichnis um ein Dateisystem handelt, dessen Inhalt allerdings nur zur Laufzeit des Systems vorhanden ist. Viele Programme, wie z. B. top, ps und die Systeminformation im KDE-Kontrollzentrum lesen Informationen aus dem /proc-Dateisystem aus und präsentieren sie in kompakter Form.

Auf den Grund gegangen

Wichtig für administrative Aufgaben ist die genaue Kenntnis der in den Rechner eingebauten Hardware. Wie Sie solche Informationen erlangen und nutzen, können Sie in LinuxUser 02/2001 [1] nachlesen. Mit Hardware-Informationen ist das Potential des /proc-Verzeichnisses jedoch noch lange nicht erschöpft. Die Frage, ob Ihr Kernel das Mounten bestimmter Dateisysteme unterstützt, wird in der Datei /proc/filesystems beantwortet:

[andi@gemini andi]$ cat /proc/filesystems
nodev   rootfs
nodev   bdev
nodev   proc
nodev   sockfs
nodev   tmpfs
nodev   shm
nodev   pipefs
        ext2
nodev   ramfs
nodev   devfs
nodev   devpts
        xfs
        vfat

Der verwendete Kernel kann die Dateisysteme ext2, xfs und vfat mounten, jedoch keine NTFS-Partitionen, wie Sie von der Windows-NT-Familie verwendet werden. Bei den Dateisystemen mit vorangestelltem nodev handelt es sich, ebenso wie bei /proc, um virtuelle oder Pseudo-Dateisysteme. In der Dokumentation zu den Kernel-Quellen finden Sie ausführliche Informationen zu diesen geräteunabhängigen Dateisystemen.

Vermuten Sie bei einer Fehlfunktion Ihres Systems ein Kernel-Problem und suchen Hilfe in einer Newsgroup, sollten Sie die Versionsnummer des Kernels wissen und mit welcher Compiler-Version dieser übersetzt wurde. Wie Sie sicher schon vermuten, findet sich auch in diesem Fall die entsprechende Auskunft in /proc:

[andi@gemini andi]$ cat /proc/version
Linux version 2.4.18-xfs-1.1 (andi@gemini.localdomain) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release / Mandrake Linux 8.2)) #2 Sun Jun 16 13:13:24 CEST 2002

Verwendet wird in diesem Fall Kernel 2.4.18, welcher mit der Compiler-Version egcs-2.91.66 gebaut wurde. Mit diesen Angaben und einer exakten Problembeschreibung haben Sie gute Chancen, kompetente Antworten zu Kernel-Problemen zu erhalten.

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

/proc ausgelesene Umgebungsvariablen eines Prozesses” width=”300″ height=”187″ /> 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.

Es darf geschrieben werden

Das letzte Ziel unserer Reise durch das /proc-Verzeichnis führt uns in das Unterverzeichnis /sys, in dem Angaben zu den Kernel-Parametern verwaltet werden, von denen Sie einige sogar verändern können. Manche Dateien beinhalten lediglich Informationen, wie /proc/sys/kernel/version. Interessanter für administrative Aufgaben sind die zur Laufzeit veränderbaren Parameter. Sollten Sie eins der folgenden Beispiele nicht nachvollziehen können, da Sie die entsprechende Datei nicht auf Ihrem System finden, ist das kein Grund zur Besorgnis. Der Füllstand des Unterverzeichnisses /sys hängt von der Konfiguration des verwendeten Kernels ab. Einen Überblick über alle dort gespeicherten Parameter verschaffen Sie sich mit

sysctl -a | less

Im ersten Beispiel finden Sie die Lösung zu dem am Anfang des Artikels angesprochenen Port-Forwarding-Problem. Wenn Sie Ihren Rechner als Router konfigurieren möchten und überzeugt sind, alle Einstellungen richtig gemacht zu haben, es aber trotzdem nicht funktioniert, kann das daran liegen, dass Ihr Kernel zwar grundsätzlich Port Forwarding beherrscht, aber gar nicht weiß, dass er das für Sie leisten soll. Kontrollieren können Sie das mittels

[andi@gemini andi]$ cat /proc/sys/net/ipv4/ip_forward
0
[andi@gemini andi]$

Im Unterverzeichnis /net von /proc/sys sind, wie der Name schon vermuten lässt, Netzwerk-spezifische Variablen gespeichert, die glücklicherweise aussagekräftige Namen tragen. Liest man eine dieser Variablen aus, erhält man entweder 0 oder 1 als Rückgabewert, wobei 0 für falsch (“false”) und 1 für wahr (“true”) steht. Der Rückgabewert 0 bestätigt die Vermutung, dass der Kernel noch gar nichts von seiner neuen Aufgabe weiß. Indem Sie die 0 durch eine 1 ersetzen, ändern Sie das. Dazu führen Sie als Benutzer root folgenden Befehl aus:

echo 1 > /proc/sys/net/ipv4/ip_forward

Die Zahl 1 wird mittels > nach /proc/sys/net/ipv4/ip_forward umgeleitet. Ein erneutes Auslesen der Variable zeigt die Änderung:

[andi@gemini andi]$ cat /proc/sys/net/ipv4/ip_forward
1

Manche Distributoren, wie z. B. Mandrake, setzen diese Variable aus Sicherheitsgründen standardmäßig auf Null. Kommt dazu ein fehlerhaftes Programm zur Netzwerkkonfiguration (etwa durch einen Tippfehler des Programmierers), kommen Sie dem Problem nur durch Kenntnis des Speicherortes dieser Variablen auf die Spur.

Nicht nur bei Netzwerkproblemen ist das /proc/sys-Verzeichnis hilfreich. Wenn Sie einen aktuellen, aber noch fehlerhaften Treiber für Ihre Hardware benötigen, der gelegentlich zu einem Einfrieren des Systems führt, ist es sinnvoll die magic-SysRq-Key-Funktion des Kernels zu aktivieren, bis eine fehlerfreie Version des Treibers zur Verfügung steht.

Das ist zwar keine schöne Lösung, kann Ihr Dateisystem aber vor Schäden bewahren. Aktiviert werden die magischen Tasten als Superuser root mittels

echo 1 > /proc/sys/kernel/sysrq

Auf immer und ewig

Es ist zwar praktisch, Kernel-Parameter zur Laufzeit verändern zu können, aber da es sich bei /proc um ein virtuelles Dateisystem handelt, werden Ihre Änderungen nicht dauerhaft gespeichert und gehen bei einem Neustart des Systems verloren. Zur Lösung des Problems gibt es zwei Möglichkeiten. Schreiben Sie die benötigten Befehle in eine Startdatei Ihrer Distribution. Der Speicherort variiert allerdings von Anbieter zu Anbieter. Für SuSE heißt die Datei beispielsweise boot.local und liegt unter /etc/init.d/. Distributionsunabhängig ändern Sie die Default-Werte in der Datei /etc/sysctl.conf, zu der auch eine Manpage existiert. Als Beispiel für den Aufbau der Datei können Sie Listing 2 verwenden.

# Forwarding deaktivieren
net.ipv4.ip_forward = 0
# SysRq-Key aktivieren
kernel.sysrq=1
#Schutz vor IP-Spoofing einschalten
net.ipv4.conf.all.rp_filter=1

Bei den mit # beginnenden Zeilen handelt es sich um Kommentare. Eventuell finden Sie in der Datei sysctl.conf schon einige Einstellungen Ihres Distributors. Da es sich dabei um Kernel-Parameter handelt, ist die Dokumentation der Kernel Sourcen die erste Anlaufstelle, um sich über die Bedeutung der dort getroffenen Einstellungen zu informieren.