Unix-Systeme sind nichts für Zartbesaitete: In der Welt der Prozesse wird gekillt und gestorben, wimmelt es von Zombies und Daemonen.

Welches Programm hält das Laufwerk fest?

Nachdem ich eine CD mit Grafiken auf meinem Linux-Rechner angesehen hatte, hatte ich folgendes Problem: Beim Versuch, das CD-Laufwerk auszuhängen, kam die Fehlermeldung:

umount: /media/cdrom: Das Gerät wird momentan noch benutzt.

Wie bekomme ich heraus, welches Programm ein umount verhindert?

Abbildung 1: Welches Programm hält das Laufwerk fest?

Dr. Linux: Ob auf einer grafischen Oberfläche die Fehlermeldung aus Abbildung 1 aufpoppt oder auf einer Kommandozeile die beschriebene Zeile bzw. die englische Version

umount: /media/cdrom: device is busy

erscheint – die Fahndung nach dem Prozess, der das Laufwerk bindet, leitet man ganz einfach mit dem Befehl lsof (“list open files”; liste offene Dateien auf) ein. Dieses Kommando lässt sich so vielseitig einsetzen, dass die passende Manpage über 2000 Zeilen enthält. Es ist in der Regel unter /usr/sbin zu finden – sofern Ihr Suchpfad dieses Verzeichnis nicht enthält, müssen Sie den Befehl statt mit einem einfachen lsof als /usr/sbin/lsof aufrufen.

Als Argument übergeben Sie ihm den Namen und ggf. den Pfad der Datei, von der Sie wissen wollen, welche Prozesse auf sie zugreifen; im Fall eines blockierten CD-Laufwerks die Pfadangabe der entsprechenden Gerätedatei. Ohne Angabe eines Beobachtungsobjekts präsentiert Ihnen lsof alle offenen Dateien Ihres Systems, eine Liste also, die Kurzgeschichtenlänge erreichen kann und nur in Ausnahmefällen nützlich ist.

Wenn Ihnen Windows-Laufwerksbuchstaben noch geläufig und Sie unsicher sind, wie genau Ihr CD-Laufwerk unter Linux heißt, schlagen Sie das schnell mit dem Befehl mount nach. mount ohne weitere Angaben listet alle derzeitig eingehängten Laufwerke auf, darunter selbstverständlich auch die CD, die sich nicht unmounten lässt:

perle@maxi:~> mount
/dev/hda7 on / type ext3 (rw)
[…]
/dev/hdb on /media/cdrom type iso9660 (ro,nosuid,nodev,user=perle)

Im Beispiel hängt das CD-ROM-Laufwerk als Slave am primären IDE-Controller (/dev/hdb), die auf der CD enthaltenen Daten sind unterhalb des Verzeichnisses /media/cdrom im Linux-Dateibaum einzusehen. Am Filesystem-Typ iso9660 erkennt man, dass es sich um eine Daten-CD handelt.

Ein lsof /dev/hdb sorgt nun für eine Ausgabe wie in Listing 1. Um zu erfahren, welche Prozesse auf Daten auf der CD zugreifen, schauen wir uns insbesondere die folgenden Ausgabespalten an:

• Die Spalte COMMAND gibt das zugreifende Kommando aus, eventuell auf neun Buchstaben verkürzt.
• PID enthält die Prozess-Identifikationsnummer, die man beispielsweise braucht, um den entsprechenden Prozess mit dem kill-Befehl ins Nirvana zu schicken.
• In der dritten, mit USER überschriebenen Spalte gibt lsof den Namen des Anwenders aus, der den Prozess angeschubst hat, unter Umständen lediglich dessen Benutzer-ID (UID).

perle@maxi:~> lsof /dev/hdb
COMMAND  PID  USER    FD   TYPE  DEVICE   SIZE  NODE  NAME
 gs      1252 perle    3r   REG   3,64 593581 47726 /media/cdrom/autoren.pfd

Wenn Sie unter COMMAND ein Programm finden, das Sie selbst gar nicht gestartet haben und der Sache vollständig auf den Grund gehen wollen, lohnt sich der Einsatz des Klassikers pstree. Dieses Kommando stellt Prozesse in Baumform dar, so dass Sie schnell den Überblick darüber bekommen, welche Prozesse welche anderen Prozesse gestartet haben. Mit der Option -p enthält die pstree-Ausgabe auch die jeweiligen PIDs in Klammern (Abbildung 2). Natürlich gibt es auf allen grafischen Oberflächen Programme zur Prozessverwaltung. Wenn Sie mit einem davon Freundschaft geschlossen haben, können Sie es selbstverständlich als Alternative zu pstree einsetzen, das auf allen, auch älteren, mit wenig Hauptspeicher ausgestatteten Systemen läuft.

Abbildung 2: pstree stellt Prozesse in Baumform dar

Verhindern Prozesse das Aushängen der CD, die Sie unter Ihrer User-ID gestartet haben, können Sie sie mit dem Befehl kill und der jeweiligen PID als Argument abschießen. Reagiert der Prozess darauf nicht, setzen Sie ihm mit kill -9 die Pistole auf die Brust:

perle@maxi:~> kill -9 1252

Prozesse anderer User darf lediglich root abschießen; dass Sie mit root-Vollmachten ausgestattet besonders vorsichtig vorgehen sollten, ergibt sich dabei von selbst. Sobald der fragliche Prozess sein Leben ausgehaucht hat, steht einem umount der CD nichts mehr im Wege.

Läuft’s oder läuft´s nicht?

Bei der Konfiguration von Diensten, die durch Daemonen gesteuert werden (zum Beispiel cron), finde ich in der Dokumentation häufig die Aufforderung, zu überprüfen, ob der jeweilige Daemon oder das Programm läuft. Wie stelle ich das schnell und einfach fest?

Dr. Linux: In der /var-Abteilung des Linux-Verzeichnisbaums finden Sie Daten, die sich schnell ändern können, ergo variabel sind. Dazu zählt auch die Information, ob ein bestimmter Daemon läuft. Wird er gestartet, erhält er (wie jeder andere Task auch) eine Prozess-ID, die jedoch anders als bei “normalen” Prozessen in einer Datei namens “name.pid” in /var/run verzeichnet wird. Damit wird verhindert, dass einer der Daemonen doppelt gestartet wird, und beim Herunterfahren des Systems ist sofort ersichtlich, welche Dienste beendet werden müssen.

Finden Sie einen auf einen Daemon passenden Eintrag in /var/run, können Sie im Normalfall davon ausgehen, dass der entsprechende Dienst gestartet ist (Listing 2). Natürlich kann es sein, dass er zum aktuellen Zeitpunkt gar nichts tut und sich nur die Zeit bis zu seinem nächsten Termin vertreibt; das ist abhängig von seiner Aufgabe und der jeweiligen Konfiguration.

Wenn Sie die Prozess-ID benötigen, schauen Sie sich den Inhalt der Datei am besten mit cat an – die Ausgabe beschränkt sich auf nur eine Zahl, so dass der Einsatz eines Pagers wie less zuviel des Guten wäre:

perle@maxi:/var/run> cat cron.pid
599

Der aktuell laufende Cron-Daemon trägt also die PID 599.

perle@maxi:/var/run> ls -l
insgesamt 112
-rw-r--r--    1 root     root            4 Mär  6 09:26 atd.pid
-rw-r--r--    1 root     root            4 Mär  6 09:26 cron.pid
-rw-r—–    1 root     root            4 Mär  6 09:26 gpm.pid
-rw-r--r--    1 root     root            4 Mär  6 09:26 inetd.pid
-rw-r--r--    1 root     root            4 Mär  6 09:26 klogd.pid
-rw-r--r--    1 lp       lp              4 Mär  6 09:26 lpd.printer
-rw-r--r--    1 root     root            4 Mär  6 09:26 nscd.pid
drwxr-x--T    2 root     root         4096 Mär  6 10:18 sendmail
-rw-r--r--    1 root     root           38 Mär  6 10:18 sendmail.pid
drwxr-x—    2 root     dialout      4096 Mär  6 09:26 smpppd
-rw-r--r--    1 root     root            4 Mär  6 09:26 sshd.pid
-rw-r--r--    1 root     root            4 Mär  6 09:26 syslogd.pid
-rw-rw-r--    1 root     tty          3456 Mär  6 10:29 utmp
-rw-r--r--    1 root     root            4 Mär  6 09:26 xfstt.pid
[…]

Eine weitere Möglichkeit, sich von der Lebendigkeit eines Programms zu überzeugen, steht mit dem Befehl pidof (bei SuSE im meist nicht im Benutzer-Pfad enthaltenen Verzeichnis /sbin abgelegt) zur Verfügung, einem Link auf das Programm killall5. Übergeben Sie pidof den Namen des gesuchten Programms, das in diesem Fall nicht einmal ein Daemon sein muss. Läuft es, erhalten Sie als Ausgabe seine PID; wurde es mehrfach gestartet, gibt pidof alle Prozess-Identifikationsnummern aus.

perle@maxi:~>/sbin/pidof /sbin/syslogd
337

Sollte pidof sich nach Ihrer Eingabe ausschweigen, haben Sie es mit einem Skript zu tun (oder mit etwas, das pidof für eines hält, wobei diese Einschätzung nicht stimmen muss). In diesem Fall geben Sie die Option -x mit an:

perle@maxi:~> /sbin/pidof -x kdeinit
1125 929 927 923 921 919 909 895 893 89

Hollywoods Alpträume im System?

Wenn ich top aufrufe, um die Systemauslastung zu überprüfen, finde ich manchmal einen oder mehrere Zombies im System (Listing 3). Was bedeutet das?

Dr. Linux: Der Film “Dawn of the Dead”, der hierzulande “Zombie” hieß, definiert diesen Begriff so: Wenn in der Hölle kein Platz mehr ist, dann kehren die Toten auf die Erde zurück.

Wem jetzt bereits vor seinem Linux-System gruselt, kann sich beruhigt zurücklehnen, obwohl auch in der Unix-Welt gestorben wird, und zwar von Prozessen, wenn sie sich beenden oder beendet werden. Ein Zombie ist ein toter Prozess, dessen Exit-Status vom Kernel weiterhin in der Prozesstabelle vorgehalten wird und darauf wartet, dass sein Elternprozess ihn liest. Erst dann kann er in Frieden aus der Prozesstabelle gelöscht werden. Stirbt der Elternprozess, bevor er diesen Zahlenwert gelesen hat, wird der Zombie ebenfalls gelöscht.

 1:01am up 13:29, 1 users, load average: 0.25, 0.19, 0.1288 processes: 86 sleeping, 2 running, 1 zombie, 0 stoppedCPU states: 7.2% user, 8.0% system, 0.0% nice, 84.6% idleMem: 320072K av, 293952K used, 26120K free, 0K shrd, 16496K buffSwap: 305152K av, 3276K used, 301876K free 140224K cached
  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1719 perle     19   0  9224 8860  7164 R     8.0  2.7   0:25 kdeinit
 1286 root      16   0 22264  13M  1720 S     5.7  4.3   9:40 X
 4808 perle     14   0  1096 1096   792 R     1.3  0.3   0:09 top
    1 root       9   0   208  208   176 S     0.0  0.0   0:04 init
[…]
 1445 root       9   0     0    0     0 Z     0.0  0.0   0:00 cron <defunct>
[…]

Hintergrund oder Vordergrund?

Dass ich auf einer Kommandozeile Programme im Hintergrund starten kann, wenn ich ein & hinter den Aufruf setze, ist mir bekannt. Mit welchem Befehl hole ich mir aber einen von mehreren Hintergrund-Prozessen wieder in den Vordergrund zurück, so dass ich sie beispielsweise mit [Strg-C] beenden kann?

Dr. Linux: Programme, die auf einer Kommandozeile in den Hintergrund geschickt werden, um die Konsole nicht zu blockieren, bezeichnet man als Jobs. Beim Start eines Jobs erhält der Befehl zusätzlich zu seiner Prozessnummer eine Klammern gesetzte Ziffer, die so genannte Job-Nummer.

perle@maxi:~> emacs &
[1] 1650

Die Hintergrundprozesse lassen sich für jede Konsole (und jedes X-Terminal) mit dem Befehl jobs auflisten:

perle@maxi:~> jobs
[1]   Running                 emacs &
[2]-  Running                 gimp &
[3]+  Running                 xtetris &

Die aktiven Hintergrund-Programme sind mit Running gekennzeichnet, (englisch für “laufend”). Möglich ist auch Stopped für unterbrochene Programme, Terminated (deutsch: Beendet) oder Done. Ferner finden Sie Minus- und Pluszeichen vor. + kennzeichnet den zuletzt gestarteten Hintergrundprozess, – den vorhergehenden. Diese Zeichen können als Argumente mit vorangestelltem Prozentzeichen (%) an den Befehl fg übergeben werden, der einen Hintergrundprozess in der Vordergrund (englisch: “foreground”) holt. Weitere mögliche Argumente wären

• %n, wobei n durch die Job-Nummer, also die in Klammern gesetzte Zahl, ersetzt werden muss.
• %e, das den Job, dessen Befehlszeile mit der Zeichenkette e anfängt, in den Vordergrund holt. Wenn mehr als ein Hintergrundbefehl auf die Zeichenkette passt, erhalten Sie eine Fehlermeldung:

bash: fg: ambigious job spec: e

Das bedeutet in etwa “Mehrdeutige oder verschwommene Job-Spezifikation: e”.

• %?s, das den Hintergrundprozess hervorholt, dessen Befehlszeile die Zeichenkette s enthält (oder sich über eine mehrdeutige Job-Spezifikation beschwert).
• %% oder %+, die beide den aktuellen Job meinen.
• %-, das für den vorhergegangenen Job steht.

fg ist jedoch nicht der einzige Befehl, der bei der Job-Verwaltung in der bash hilft. Auch die folgenden Kommandos nehmen die eben beschriebenen Argumente entgegen:

• bg schickt einen Job in den Hintergrund. Damit bg in einer von einem Vordergrundprozess blockierten Shell überhaupt eingegeben werden kann, muss dieser mit [Strg-Z] vorübergehend gestoppt werden.
• kill beendet den als Argument angegebenen Job. Passt das Muster auf mehrere Prozesse, gibt es allerdings eine Fehlermeldung.
• Auch die Auflistung der Jobs mit jobs lässt sich mit den besprochenen Argumenten auf bestimmte Prozesse beschränken. Praktisch sieht das etwa so aus:

perle@maxi:~> jobs
[1]   Running                 emacs &
[2]-  Running                 gimp &
[3]+  Running                 xtetris &
perle@maxi:~> kill %1
perle@maxi:~> jobs
[1]   Beendet                 emacs
[2]-  Running                 gimp &
[3]+  Running                 xtetris &

Bevor Sie Dateien-bearbeitende Programme wie den Emacs abschießen, sollten Sie jedoch einen Moment innehalten. Mit kill verlagern Sie Ihre ungesicherten Text-Dateien nämlich ebenfalls ins Nichts. Verlassen Sie die Konsole, aus der das Programm gestartet wurde, mit exit, bleibt Ihnen der Editor allerdings erhalten, und Sie können Ihre Daten ggf. noch sichern.

Liegen im mit exit zu beendenden Terminal noch unterbrochene Jobs in Warteposition, werden Sie freundlich daran erinnert:

There are stopped jobs.

Erst auf ein zweites exit hin verabschiedet sich die Konsole von Ihnen.