Wenn man die Maschine nicht kennt, sollte man sich erst informieren, was für ein System man vor sich hat. Die Maschine, das Betriebssystem, die Version werden von dem Kommando uname ausgegeben.

gaston# uname -a Linux gaston 2.2.16 #1 Wed Aug 2 20:22:26 GMT 2000 i686 unknown hpsrv$ uname -a HP-UX hpsrv B.10.10 A 9000/816 1962328252 two-user license note$ uname -a FreeBSD note.willemer.edu 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Sep 18 11:57:08 PDT 2001 murray@builder.FreeBSD.org:/usr /src/sys/compile/GENERIC i386

Flag	Bedeutung	Beispiel Linux	Beispiel HP	Beispiel FreeBSD
-s	Name des Betriebssystems	Linux	HP-UX	FreeBSD
-n	nodename	gaston	hpsrv	note.willemer.edu
-r	release	2.2.16	B.10.10	4.4-RELEASE
-m	machine	i686	9000/816	i386

Die Informationen von uname sollte man auch greifbar haben, wenn man eine Hotline kontaktiert. Die Wahrscheinlichkeit ist hoch, dass man nach diesen Informationen gefragt wird.

Die Protokolldateien des syslog Dämons

/etc/syslog.conf

In der /var/log/messages finden sich alle Ereignisse historisch sortiert. Alle sind mit Datum und Uhrzeit versehen. Man braucht ein wenig Übung, um sich in dieser Datei zurecht zu finden. Darum ist es durchaus sinnvoll, sie auch dann zu lesen, wenn gerade mal nichts passiert ist. Ungewöhnliches kann man dann im Ernstfall schneller identifizieren.

syslogd liest syslog.conf

news.crit /var/log/news

Das bedeutet, dass die Fehler, die vom Newssystem erzeugt werden, die mindestens kritisch sind, in die Datei /var/log/news abgestellt werden sollen.

Die Facility, also der Verursacher, kann folgende Werte annehmen:

Facility	Verursacher
kern	Kernel
user	Anwenderprogramme
mail	sendmail und Kollegen
daemon	Systemhintergrundprozesse
auth	Authorisierungsbefehle
lpr	Das Drucksystem
news	Der Newsserver
uucp	UUCP
cron	cron Dämon
mark	Zeitstempel
local0 - local7	frei verfügbar
*	alle

Mit dem Level kann festgelegt werden, wie gravierend das Problem sein muss, damit es in der Protokolldatei erscheint. Für jede Facility kann ein eigener Level bestimmt werden, ab dem eine Meldung gemacht wird. Die folgende Tabelle zeigt die Level mit nach unten abnehmender Bedeutung.

Level	Bedeutung
emerg	Panik
alert	Alarm
crit	kritisch
warning	Warnmeldungen
notice	Hinweise
info	informell
debug	Ablaufnotizen von Programmen in der Entwicklung

Normalerweise wird als Ausgabe eine Datei oder auch das Konsolendevice angegeben. Die entsprechenden Dateien müssen nach dem Eintrag angelegt werden. Der syslog-Dämon kann nämlich keine Dateien erzeugen. Es können auch mehrere Ziele angegeben werden, die durch Kommata getrennt werden. Die Dateien müssen mit vollem Pfadnamen angegeben werden. Steht dem Ziel ein @ voran, kann eine IP-Nummer oder ein Hostname angegeben werden. Dann wird die Fehlermeldung an den syslog-Dämon des betreffenden Rechners versandt.

Beispiel syslog.conf

# /etc/syslog.conf - Configuration file for syslogd(8) *.emerg * mail.* /var/log/mail *.info /var/log/messages

Der Stern als Ziel, wie oben bei den Emergencynachrichten bedeutet, dass die Mitteilung sofort an alle angemeldeten Terminals versandt wird. In der nächsten Zeile werden alle Nachrichten, die Mails betreffen in die Datei mail eingetragen. Alle restlichen Meldungen, die mindestens den Level info haben, werden in der Datei messages abgestellt, also auch die emerg-Meldungen, die damit an zwei Ziele verteilt werden.

Erweiterungen

Liveübertragung

gaston# cd /var/log gaston# tail -f messages Jun 18 20:11:36 gaston pppd[2592]: sent [LCP TermReq id=0x4 "Us er request"] Jun 18 20:11:36 gaston pppd[2592]: rcvd [LCP TermAck id=0x4] Jun 18 20:11:36 gaston pppd[2592]: Connection terminated. Jun 18 20:11:36 gaston pppd[2592]: Connect time 0.4 minutes. Jun 18 20:11:36 gaston pppd[2592]: Sent 3333 bytes, received 25 062 bytes. Jun 18 20:11:36 gaston pppd[2592]: Waiting for 1 child processe s... Jun 18 20:11:36 gaston pppd[2592]: script /etc/ppp/ip-down, p id 2616 Jun 18 20:11:36 gaston pppd[2592]: Script /etc/ppp/ip-down fini shed (pid 2616), status = 0x0 Jun 18 20:11:36 gaston pppd[2592]: Exit. Jun 18 20:26:54 gaston su: (to root) arnold on /dev/pts/6

Ausschnitte extrahieren

tail -2000 messages > guckmal

Damit sind die letzten 2000 Zeilen in der Datei guckmal gelandet. Mit dieser Dateigröße lässt sich leicht arbeiten.

Stutzen der Protokolle

> /var/log/messages

Wegrotieren von Protokolldateien

gaston# cd /var/log gaston# fuser messages messages: 378

Die Datei messages ist vom Prozess 378 im Zugriff. Vermutlich ist das der syslogd.

gaston# mv messages messages.$(date +%y%m%d) gaston# fuser messages.$(date +%y%m%d) messages.020224: 378

Die Datei wurde nun umbenannt. Immer noch ist sie im Zugriff von Prozess mit der PID 378, obwohl der Name der Datei sich geändert hat.

gaston# touch messages gaston:/var/log # l messages* -rw-r--r-- 1 root root 0 Feb 24 12:07 messages -rw-r----- 1 root root 2447648 Feb 24 12:06 messages.020224 gaston# chmod 640 messages gaston# l messages* -rw-r----- 1 root root 0 Feb 24 12:07 messages -rw-r----- 1 root root 2447648 Feb 24 12:06 messages.020224

Die neue Protokolldatei wurde erfolgreich angelegt und mit den Rechten der alten versehen. Auch der Eigentümer stimmt überein.

gaston# ps -ef | grep syslog root 378 1 0 10:24 ? 00:00:00 /sbin/syslogd root 1486 1465 0 12:09 pts/2 00:00:00 grep syslog gaston# kill -SIGHUP 378

Sicherheitshalber wird noch einmal geprüft, ob der Prozess 378 tatsächlich der syslogd ist. PID 1486 ist der eigene Prozess, der aus der Prozessliste herausfiltert. Nun wird mit dem kill der syslogd aufgefordert, die Konfiguration neu zu lesen und damit alle Dateien neu zu eröffnen.

gaston# fuser messages messages: 378 gaston# gzip messages.$(date +%y%m%d)

Erwartungsgemäß hat der syslogd die Datei messages eröffnet und damit die gerade neu untergeschobene. Die alte Protokolldatei kann gepackt werden.

Mit Hilfe des Befehls \verb+date+ wird der neue Dateinamen mit dem aktuellen Datum gekennzeichnet. Die Konstruktion $(Kommando) bewirkt dasselbe wie mit den so genannten Backquotes `Kommando`, lässt sich aber etwas leichter lesen. Es wird das Ergebnis des eingeklammerten Kommandos ermittelt und in den Befehl integriert.

Einige Programme melden ihre Fehler nicht über den syslog-Dämon, sondern verbreiten ihre Klagen per Mail. Prominentester Vertreter dieser Art ist der Druckdämon, der fehlgegangene Drucke an den Benutzer sendet, der den Auftrag gab. crontab und at senden ihre komplette Ausgabe an den Besitzer. Darum gehört ein mindestens lokales Mailsystem zur Standardinstallation. Dazu gehört auch das Standardtool mail. Leider ist die Benutzung etwas antiquiert. Es ist darum eine gute Idee, ein einfaches, aber übersichtliches Mailprogramm zu installieren wie elm oder pine. Ein grafisches Tool braucht recht viele Ressourcen, die bei einem Zusammenbruch des Servers vielleicht nicht zur Verfügung stehen.

vi statt mail

Als weiterer Wert wird die durchschnittliche Systemlast (load average) angezeigt. Schauen Sie sich diesen Wert hin und wieder an, damit Sie ein Gefühl dafür bekommen, wie sich die Maschine im Normalzustand verhält. Als Daumenregel zeigt ein Wert über 1 eine gut belastete Maschine. Ab etwa 3 steht die Maschine unter Last.

gaston> uptime 5:11pm up 7:33, 1 user, load average: 0.06, 0.01, 0.00 gaston> uptime 11:11pm up 14:40, 1 user, load average: 0.95, 0.47, 0.28

Im Beispiel sind zwei unterschiedliche Aufrufe von uptime angezeigt. Die erste Meldung besagt, dass es 17:11 ist, der Rechner seit 7 Stunden und 33 Minuten läuft, dass ein Benutzer eingeloggt ist und dass es der Maschine richtig langweilig ist. Der zweite Aufruf wurde parallel zu einem Compilelauf kurz vor dessen Ende ausgeführt. Hier ist es 23:11, die Maschine läuft sein 14 Stunden, 40 Minuten, hat ebenfalls einen Benutzer und die Systemlast liegt bei 0.95. Andere Prozesse würden auf diesem System noch flüssig laufen, allerdings nicht ganz so schnell wie auf einer unbeschäftigten Maschine.

Prozessdefinition

Scheduler

Warteschlangen

Einer der Vorteile von UNIX ist die Möglichkeit, wirklich alle laufenden und wartenden Prozesse, ihre Zugehörigkeit und ihren Ressourcenverbrauch beobachten zu können. Als Administrator hat man dadurch viele Möglichkeiten, zu erkennen und einzugreifen, wenn etwas nicht sauber läuft.

ps zeigt die Prozessliste

Für eine Übersicht über alle auf dem System laufenden Prozesse gibt es Kombinationen von Optionen, die der Administrator fast ohne nachzudenken verwendet.

Befehl	System
ps -alx	BSD und Linux: zeigt auch PID und PPID
ps -aux	BSD: zeigt auch Benutzer
ps -elf	System V, beispielsweise SCO und HP-UX

Ohne Parameter werden nur die Prozesse gezeigt, die von dieser Sitzung erzeugt wurden. In der ersten Tabelle sind die Optionen, wie sie BSD-Systeme verwenden.

Option	Anzeige
-a	alle Prozesse, nicht nur die eigenen
-x	zeigt auch Prozesse, die keinem Terminal zugeordnet sind (z. B. Dämonen)
-u	zeigt den Benutzer des Prozesses und die Startzeit
-l	zeigt Prozess-ID des Vaterprozess und nice-Wert

Auf den System V Maschinen verwendet man meist -elf. Die Bedeutung dieser Parameter sind:

Option	Anzeige
-e	zeigt alle auf dem System laufenden Prozesse
-l	zeigt Größe, Status und Priorität jedes Prozesses
-f	zeigt UserID, PID, PPID und Startzeit

Daneben gibt es große Menge anderer Optionen, die diverse Informationen zu den Prozessen liefern. Die Manpage von ps liefert eine vollständige Liste für Ihr System.

Die Titel der Prozessliste geben Auskunft über die angezeigten Informationen.

USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.0 448 208 ? S 09:37 0:04 init [5] root 2 0.0 0.0 0 0 ? SW 09:37 0:00 [keventd] root 3 0.0 0.0 0 0 ? SW 09:37 0:00 [kapm-idled] root 4 0.0 0.0 0 0 ? SWN 09:37 0:00 [ksoftirqd_CPU0] root 5 0.0 0.0 0 0 ? SW 09:37 0:00 [kswapd] root 6 0.0 0.0 0 0 ? SW 09:37 0:00 [bdflush] root 7 0.0 0.0 0 0 ? SW 09:37 0:00 [kupdated] root 8 0.0 0.0 0 0 ? SW< 09:37 0:00 [mdrecoveryd] root 11 0.0 0.0 0 0 ? SW 09:37 0:00 [scsi_eh_0] root 13 0.0 0.0 0 0 ? SW 09:37 0:00 [khubd] root 390 0.0 0.1 1396 628 ? S 09:39 0:00 /sbin/syslogd root 393 0.0 0.3 1772 992 ? S 09:39 0:00 /sbin/klogd -c 1 root 399 0.0 0.2 2308 828 ? S 09:39 0:00 /usr/sbin/sshd bin 452 0.0 0.1 1340 428 ? S 09:39 0:00 /sbin/portmap arnold 1249 0.0 19.5 108924 62496 ? R 10:01 0:15 /opt/office52/soffice arnold 2353 0.0 0.5 2840 1620 pts/4 S 17:11 0:00 /bin/bash arnold 2416 0.0 0.5 2692 1716 pts/4 R 17:32 0:00 ps aux arnold 2417 0.0 0.2 1976 824 pts/4 R 17:32 0:00 less

Dieser Ausschnitt der Prozessliste zeigt in der ersten Zeile den Prozess init mit der PID 1. Die erste Zeile zeigt in den Überschriften, was die einzelnen Spalten anzeigen. Diese Liste ist durch den Befehl ps aux entstanden. Je nach System und Parametern sind die Spalten anders. Im folgenden sollen die wichtigsten Spalten beschrieben sein, die man durch ps anzeigen lassen kann. Welche Informationen durch welche Flags angezeigt werden, entnimmt man am besten der Manpage von ps auf dem jeweiligen System.

Kürzel	Beschreibung
USER	Benutzer, der den Prozess gestartet hat
PID	Prozess ID, wird als Argument für kill verwandt
PPID	Die Prozess ID des Elternprozesses
PGID	Prozessgruppen ID
SID	Session ID
PRI	Priorität des Prozesses. Je niedriger, desto mehr Rechenzeit
NI	Nice-Wert oder SY für Systemprozesse
%CPU	Anteil an der CPU-Auslastung
%MEM	Anteil an der Speicherauslastung
VSZ	Virtuelle Prozessgröße
RSS	Größe des residenten Speichers
TTY	das Kontrollterminal des Prozesses
STAT	Status des Prozesses, siehe unten
SIZE oder SZ	Größe des Prozesses
START oder STIME	Startzeitpunkt
TIME	Die bisher verbrauchte CPU-Zeit
WCHAN	Kernelfunktion, auf die der Prozess wartet
COMMAND	Das Kommando, mit dem der Prozess gestartet wurde

Der Prozessstatus STAT kann verschiedene Zeichen haben. R bedeutet runnable. Der Prozess ist also gerade aktiv. Im Beispiel oben sind dies beispielsweise der ps mit der PID 2416, der die Anzeige erzeugt hat. Das immer wieder auftauchende S zeigt an, dass der Prozess schläft, also auf ein Ereignis wartet, das ihn weckt.

Status	Bedeutung
R	ausführbar
S	schlafend
T	gestoppt
D	auf der Festplatte wartend
W	Prozess ist ausgelagert

Der Befehl ps kann von jedem Anwender aufgerufen werden, nicht nur von root. Dementsprechend ist es ein massives Sicherheitsloch, wenn ein Programm ein Passwort als Parameter im Klartext entgegen nimmt.

Während ps eine Momentaufname der Prozesse zeigt, stellt das Programm top die Prozesse in der Reihenfolge ihres CPU-Zeitverbrauchs dar. Wenn man also Verdacht hat, dass ein Prozess überdurchschnittlich viel CPU-Zeit verbraucht, ist top ein ideales Werkzeug. Es erstellt eine Hitparade der Prozesse. Diejenigen Prozesse, die am meisten CPU-Zeit verbrauchen, stehen in der ersten Zeile. Hier ein Beispiel für die Prozesstabelle, wie sie top anzeigt und regelmäßig aktualisiert.

11:32am up 3:04, 1 user, load average: 0.11, 0.16, 0.07 95 processes: 93 sleeping, 2 running, 0 zombie, 0 stopped CPU states: 1.7% user, 2.3% system, 0.0% nice, 95.8% idle Mem: 320136K av, 189100K used, 131036K free, 0K shrd, 5756K buff Swap: 128512K av, 0K used, 128512K free 118592K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 822 root 16 0 41876 8640 1720 S 1.9 2.6 0:39 X 1174 arnold 13 0 9180 9176 8256 R 1.1 2.8 0:01 kdeinit 1646 arnold 18 0 1004 1004 776 R 0.7 0.3 0:00 top 1 root 9 0 208 208 176 S 0.0 0.0 0:04 init 2 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd 3 root 9 0 0 0 0 SW 0.0 0.0 0:00 kapm-idled 4 root 19 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 5 root 9 0 0 0 0 SW 0.0 0.0 0:00 kswapd 6 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush 7 root 9 0 0 0 0 SW 0.0 0.0 0:00 kupdated 8 root -1 -20 0 0 0 SW< 0.0 0.0 0:00 mdrecoveryd 11 root 9 0 0 0 0 SW 0.0 0.0 0:00 scsi_eh_0 13 root 9 0 0 0 0 SW 0.0 0.0 0:00 khubd 343 news 9 0 2772 2772 1284 S 0.0 0.8 0:00 innd 346 news 9 0 880 880 732 S 0.0 0.2 0:00 actived 367 news 9 0 704 704 596 S 0.0 0.2 0:00 overchan 370 news 9 0 2460 2460 1248 S 0.0 0.7 0:00 controlchan 373 root 9 0 0 0 0 SW 0.0 0.0 0:00 usb-storage-0

nohup unterbindet SIGHUP

SIGHUP fordert zum Neueinlesen der Konfiguration auf

Der Fall, dass ein Administrator den Befehl kill tatsächlich zum Töten des Prozesses benutzt, ist tatsächlich eher selten. Ein Prozess, der von einem Anwender gestartet wurde, kann vom Administrator nicht einfach zerlegt werden. Immerhin kann es sein, dass durch den Abschuss wichtige Daten verloren gehen können. Erst wenn der Prozess durch extensiven CPU-Zeitverbrauch auffällt, wird man versuchen, etwas zu tun.

renice +5 987

Hat man den Verdacht, dass dieser Prozess Schaden anrichtet oder ist renice nicht erfolgreich genug, so kann man ihn mit dem Signal SIGSTOP anhalten und hat später die Möglichkeit, ihn mit SIGCONT wieder fortzusetzen. Gleichzeitig sollte man den Anwender verständigen, dass sein Prozess angehalten wurde, aber wieder aktivierbar ist.

kill -SIGSTOP 987 ... kill -SIGCONT 987

Ob ein Prozess eine Datei geöffnet hat, ist eine wichtige Information. Eine geöffnete Datei kann nicht einfach gelöscht werden und ein schreibender Prozess sollte nicht einfach abgeschossen werden. Es gibt also den Bedarf an Information, welche Datei von welchen Prozessen bearbeitet wird und welcher Prozess welche Dateien offen hat.

gaston> fuser unix.ps unix.ps: 1176 1190

Wendet man fuser auf ein Verzeichnis an, kann man sehen, welche Prozesse unterhalb dieses Verzeichnisses gestartet worden sind. Das ist wichtig, wenn man beispielsweise ein Dateisystem per umount ausklinken möchte und die Meldung erscheint, dass das Gerät noch in Benutzung ist.

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME init 1 root mem REG 3,5 333780 178159 /sbin/init portmap 386 root mem REG 3,5 28184 178286 /sbin/portmap portmap 386 root mem REG 3,5 342535 275298 /lib/ld-2.1.3.so portmap 386 root mem REG 3,5 44729 275322 /lib/libutil.so.1 portmap 386 root mem REG 3,5 4070406 275303 /lib/libc.so.6 syslogd 404 root mem REG 3,5 29252 485827 /usr/sbin/syslogd syslogd 404 root mem REG 3,5 342535 275298 /lib/ld-2.1.3.so syslogd 404 root mem REG 3,5 4070406 275303 /lib/libc.so.6

In der zweiten Spalte steht die PID, die man leicht per grep oder besser per awk herausfiltern kann. Der folgende Aufruf liefert alle Dateien, die der Prozess mit der PID 719 offen hat.

lsof | awk '{if ( $2==719 ) print $9 }'

Da nicht jeder Administrator auswendig den Syntax von awk zur Hand hat, funktioniert natürlich auch die einfachere Variante mit grep.

lsof | grep 719

Der Nachteil dieser unsportlichen Lösung ist natürlich, dass nun auch Zeilen herausgegriffen werden, die an anderer Stelle als in Spalte 2 die Zahl 719 haben.

sync schiebt die Puffer auf die Platte

Todesstrafe für Fehlverhalten von Prozessen

core ist ein Speicherabzug

Wenn man als Administrator eine Datei namens core findet, ist zunächst deren Alter interessant. Das Alter gibt Auskunft über den Zeitpunkt des Zusammenbruchs. Ist der verantwortliche Programmierer greifbar, wird er sich für diese Datei interessieren. Ansonsten gehören core Dateien eher zum lästigen Abfall, der bei der Entwicklung von Software nun einmal entsteht. Darum steht bei einigen Maschinen ein Eintrag in der crontab, alle älteren Dateien namens core zu suchen und zu löschen. Auf einer Produktionsmaschine sollten core dumps nicht entstehen. Insofern wäre eine Beseitigung solcher Spuren eines Zusammenbruchs nicht sehr sinnvoll.

Ein kernel panic ist ein Fehler, der so heftig ist, dass das Betriebssystem alle Tätigkeiten einstellt. Die letzte Aktion besteht darin, einen Speicherabzug in die Swappartition zu schreiben. Als Ursache eines kernel panic kommen im Normalfall eigentlich nur Probleme mit Hardware oder deren Treiber in Frage. Anwendungsprogramme haben keinen Zugriff auf Bereiche, die das System derart außer Tritt bringen können. Selbst Dämonen und Systemprozesse würden im Falle eines Amoklaufs auf die Ausnahmebehandlung des Betriebssystems laufen und einen schnellen Tod finden.