IT-Academy Logo
Sign Up Login Help
Home - Betriebssysteme - Linux - Prozesse unter Linux administrieren



Prozesse unter Linux administrieren

Konzept und Administration von Prozessen (init, Lebenszyklus, Prozessarten, Runlevel, ps, top, kill, nice).


Autor: Sebastian Fladung (SFiL)
Datum: 16-12-2003, 23:30:03
Referenzen: Aleen Frisch, Thomas Emer, Michael Meyer
Schwierigkeit: Anfänger
Ansichten: 51468x
Rating: 10 (3x bewertet)

Hinweis:

Für den hier dargestellte Inhalt ist nicht der Betreiber der Plattform, sondern der jeweilige Autor verantwortlich.
Falls Sie Missbrauch vermuten, bitten wir Sie, uns unter missbrauch@it-academy.cc zu kontaktieren.

[Druckansicht] [Als E-Mail senden] [Kommentar verfassen]



Einleitung

Ein Prozess ist vereinfacht ausgedrückt ein einzelnes ausführbares Programm (Befehl), das in seinem eigenen Adressraum abläuft. Beispiel: der Befehl ls, zeigt alle Dateien und Verzeichnissen in den aktuellen Verzeichnis an. Es ist ein Prozess. Wenn in Linux ein Prozess gestartet wird, wird eine Nummer (PID oder Prozess-ID) vergeben. Diese kann eine Nummer zwischen 0 und 65535 sein.

fladung@linux-sf:~> ls
bin Desktop Documents public_html tmp
fladung@linux-sf:~>


Mehrere Prozesse bilden einen Befehl

Ein Befehl unterscheidet sich von einem Job oder einem Prozess, dadurch das er aus mehreren Prozessen bestehen kann, die zusammen eine bestimmte Aufgabe ausführen.

Hier im Beispiel wird erst einmal mit dem Befehl ls alle Dateien und Ordner des Systems angegeben. Mit der Pipe (|) wird die Ausgabe des ersten Prozesses (ls) weiter übergeben an den weiteren Prozess (grep). Der Prozess grep durchsucht nun die aufgelisteten Dateien nach „.bash“ und gibt sie anschließend aus.

fladung@linux-sf:~> ls -alf | grep .bash
.bashrc
.bash_history
fladung@linux-sf:~>


Konzept

Es gibt verschiedene Arten von Prozessen unter UNIX/Linux:
  • Interaktive Prozesse
  • Batch-Prozesse
  • Daemons
Interaktive Prozesse

Interaktive Prozesse werden von einer Terminal Sitzung aus gestartet und kontrolliert. Sie können entweder im Vordergrund oder im Hintergrund ablaufen.

Vordergrundprozesse bleiben an das Terminal gekoppelt, das Terminal kommuniziert direkt mit ihnen. Sie führen immer dann einen Vordergrundprozess aus, wenn Sie einen Unix-Befehl eingeben und auf seine Ausgabe warten. Läuft ein Vordergrundprozess ab, so nimmt nur er direkte Eingaben vom Terminal entgegen. Es lässt sich nur ein weiterer Befehl eingeben, wenn sich regulär der Prozess beendet hat, oder Sie ihn mit Strg-C abgebrochen haben.

fladung@linux-sf:/ # ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.033 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.034 ms


Job-Kontrolle

Job-Kontrolle ermöglicht das beliebige Bewegen von Prozessen in den Vorder- oder Hintergrund. Wird ein Prozess aus dem Vordergrund in den Hintergrund verschoben, wird er vorübergehend gestoppt. Die Kontrolle wird an den übergeordneten Prozess, den so genannten Elternprozess übergeben (in der Regel die Shell). Der Hintergrund-Job kann wieder aufgenommen werden und losgelöst von der Terminal-Sitzung weiterlaufen, über die er gestartet wurde. Er kann aber auch wieder in den Vordergrund geholt werden.

fladung@linux-sf:/ # ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.030 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.035 ms

[1]+ Stopped ping localhost
fladung@linux-sf:/ #


Ebenfalls ist es möglich, den Prozess direkt als Hintergrundprozess zu starten.

fladung@linux-sf:~> ping localhost > protokoll.txt &
[1] 4288
fladung@linux-sf:~>


Befehl Bedeutung
& Befehl im Hintergrund ausführen
$ ping localhost > protokoll.txt &
Strg + Z Vordergrundprozess stoppen
jobs Hintergrundprozess anzeigen lassen

Zusätzliche Optionen
-l Zusätzliche Anzeige der PID
-n Nur Prozesse anzeigen, deren Status sich seit dem letzten Aufruf von jobs geändert hat
-p Nur die PIDs anzeigen
-r Nur aktive Prozesse anzeigen
-s Nur gestoppte Prozesse anzeigen
$ jobs
[1]+ Running ping localhost >protokoll.txt &
$
%n Zugriff auf Hintergrundprozess n
$ kill -9 %1
[1]+ Getötet ping localhost >protokoll.txt
$
fg Hintergrundprozess in den Vordergrund holen
$ fg %1
ping localhost >protokoll.txt
bg Erneutes Starten eines gestoppten Hintergrundprozesses
$ping localhost > protokoll.txt
[1]+ Stopped ping localhost >protokoll.txt
$
$bg
[1]+ ping localhost >protokoll.txt &
$


Batch-Prozesse

Batch-Prozesse sind nicht an ein Terminal gebunden. Sie werden in eine Warteschlange eingereiht, aus der die Jobs sequentiell abgearbeitet werden.

cd /home/fladung/backup
mkdir `date +%Y-%m-%d`
cd `date +%Y-%m-%d`
cp /etc/apache2/* apache2 –dpr
-wird in ein Verzeichnis gesprungen
-ein Ordner mit dem aktuellen Datum erstellt
-In das Verzeichnis hinein gesprungen
-Die Konfigurationsdateien des Apache2 werden hineinkopiert


Daemons

Daemons sind Server-Prozesse, die in der Regel beim Booten gestartet werden. Während des gesamten Systembetriebs laufen und im Hintergrund warten, bis Prozesse ihre Dienste in Anspruch nehmen. Ein Netzwerk-Daemon ist z.B. so lange untätig, bis ein Prozess einen Zugriff auf das Netzwerk anfordert.

Name der Einrichtung Aufgabe Daemon Name
init Der erste Prozess, der nach dem Systemstart erzeugt wird. Er initalisiert das System. init
syslog Logging des Systemstatus und von Fehlermeldungen syslog
inetd Übergeordneter TCP/IP Daemon, der abhängig von seiner Konfiguration den eigentlichen gewünschten Netzwerk-Daemon startet. (httpd, telnetd, sshd, ftpd, pop3d, ...) inetd
Samba Datei- und Druckjobaustausch mit Windows- Systemen Smbd, nmbd
Apache HTTP- Server httpd


Lebenszyklus eines Prozesses

Ein neuer Prozess entsteht, indem eine exakte Kopie eines momentan ablaufenden Prozesses angefertigt wird. Dieser Vorgang heißt Forking. Der neue Prozess, Kinderprozess (Child-Prozess) genannt, erbt seine Umgebung vom Elternprozess (Parent-Prozess), obwohl er eine andere Prozess-ID zugeordnet bekommt. Danach wird der Adressraum des Kinderprozesses mit Hilfe des Systemaufrufes exec von dem neuen Programm eingenommen (daher stammt die häufige benutzte Phrase fork- und exec). Das neue Programm (der neue Befehl) ersetzt vollständig das Duplikat des Elternprozesses.

Beispiel:
Was passiert, wenn ein Benutzer den Befehl wie z.B. ps startet?
Zunächst führt die Shell ein Forking aus, das heißt es erzeugt eine Kopie ihrer selbst. Damit wird ein neuer Prozess erzeugt, der den Befehl ausführen kann. Dann wird die neue Shell im RAM von ps überlagert (exec). Der neue Prozess stirbt, sobald der grep -Befehl abgearbeitet ist.

Nach diesem Schema werden alle Prozesse unter Unix/Linux abgearbeitet. Der Urahn aller Prozesse ist der init mit der Prozess- ID 1, der während des Boot-Vorgangs erzeugt wird. Der init Prozess startet über den fork und exec Mechanismus eine Reihe weiterer Prozesse. Darunter fallen in der Regel einer oder mehrere Prozesse, die das getty- Programm (per exec) ausführen. Sie schreibt das Login-Promt auf das Terminal und wartet auf die Eingabe des Benutzers und dessen Passwortes. Wenn sich ein Benutzer einloggt hat, führt der getty-Prozess das Login-Programm aus, das unter anderem die Benutzer-Logins überprüft. Nach erfolgreicher Anmeldung führt login die Shell des Benutzers aus. Das Forking wird also nicht zwingend für die Ausführung eines neuen Programms benötigt – login in diesem Fall führt zu keinem Fork.




init Prozess

Der Ursprung aller Prozesse und „Prozessfamilien“ liegt im init-Prozess, der als erster Prozess beim Start des Systems mit der Prozessnummer (PID) 1 ins Leben gerufen wird, und dann die weiteren Programme des Systems startet. Er nimmt somit eine Sonderrolle ein. Der init-Prozess wird vom Kernel gestartet, und ist immun gegen das Signal 9, mit dem normalerweise jeder Prozess „gekillt“ wird. Alle weiteren Prozesse, werden entweder von init selbst, oder von einem seiner „Kinderprozesse“ gestartet.

Der UNIX/Linux Boot teilt sich in verschiedene Phasen:
  • Grundsätzliche Hardwareerkennung (Arbeitsspeicher, Festplatte, Tastatur, Maus, etc.)
  • Ausführung der Firmware des Systems
  • Aufspüren und Ausführen des initalen Boot-Programms (durch das Firmware-Boot-Programm), in der Regel vom einem festgelegten Ort auf der Festplatte. Dieses Programm kann vor dem Laden des Kernels noch zusätzliche Hardware-Tests durchführen.
  • Aufspüren und Starten des Kernels (vom Boot Programm der ersten Stufe). Die Image-Datei, die den auszuführenden Kernel enthält, kann entweder automatisch bestimmt oder durch manuelle Eingabe an das Boot-Programm übergeben werden.

  • Der Kernel initialisiert sich selbst und führt dann die letzten Hardware-Tests der obersten Stufe durch und lädt dabei die benötigten Gerätetreiber und/oder Kernel-Module
  • Der Kernel startet den init-Prozess, der dann seinerseits die Systemprozesse (Daemons) startet und sämtliche aktiven Subsysteme initialisiert. Ist alles vorbereitet, können sich die Benutzer einloggen.
Der init-Prozess ist somit der Vorfahre aller folgenden Unix/Linux-Prozesse und direkter Elternprozess aller Login-Shells. Während des übrigen Boot-Vorgangs führt init alle nötigen Arbeiten durch, um das System für die Benutzer vorzubereiten.

Bis zum Starten des init-Prozess konnte der Administrator nur über Optionen, die dem Kernel auf der Bootzeile angegeben werden, oder durch Erzeugen eines neuen Kernels den Bootvorgang steuern. Mit dem Laden des Programms init in die Umgebung des ersten Prozesses beginnt die eigentliche administrative Einflussnahme.

Eine der ersten Aufgaben des init besteht darin, Integrität des lokalen Dateisystems festzustellen. Am Anfang steht das Root-Dateisystem sowie weitere wichtige Dateisysteme wie z.B. /root und /usr. Da der Kernel und das init- Programm sich selbst im /root bzw. Teile auch im /usr Dateisystem befinden, ist jetzt die Frage, wie diese ausgeführt werden können, ohne das das betreffende Dateisystem zuvor überprüft worden ist. Hierbei gibt es verschiedene Möglichkeiten.
  • in der Boot-Partition auf der Festplatte ist das eine Kopie des Kernels
  • man geht davon aus, dass alles OK ist, Aübernimmt der Kernel anschließend selbst das Überprüfen und Mounten des Root-Dateisystems.
    • Aufgaben von init:
    • Überprüfen der Integrität des Dateisystems (traditionellerweise mit dem Programm fsck)
    • Mounten lokaler Festplatten
    • Festlegen von Paging-Bereichen (Virtueller Speicher)
    • Aufräumen der Dateisysteme (aufbewahren von Sicherheitskopien, Löschen temporärer Dateien)
    • Starten der Systemprozesse (Daemons) für Drucken, Accounting, Fehlerlogging, cron
    • Starten der Netzwerk-Daemons und nicht lokaler Festplatten
    • Ermöglichen von Benutzer-Logins, normalerweise durch das Starten des getty-Prozesses und / oder dem grafischen Login (z.B. xdm)
Die Runlevel

Ein Runlevel definiert einen Zustand des Unix/Linux-Systems. Unter einem Zustand verstehen wir eine bestimmte Konstellation aktiver Prozesse, die während des Bootvorgangs initiiert wurden. So werden in einem Netzwerk-Runlevel zahlreiche Dämonenprozesse gestartet (z.B. inetd, httpd,...), die in einem Modus ohne Netzwerk nicht notwendig sind und demzufolge in dessen Konstellation nicht erscheinen.

Prinzipiell stehen die Runlevel 0 bis 9, a, b, c und s zur Verfügung. 0 und 6 sind dabei von vornherein mit bestimmten Funktionalitäten versehen, die Verwendung der weiteren Level ist stark distributionsabhängig. Traditionell werden die Runlevel 7-9 nicht verwendet, auch a-c sucht man bei den verbreiteten Distributionen vergeblich. „s“ wird häufig als Single User Modus verwendet. Die hinter einem Runlevel stehende Konstellation ist hochgradig konfigurierbar und es steht in der Verantwortung des Administrators, welche Dienste in welchem Zustand im System residieren.

Dennoch stellen alle Distributionen mit der Neuinstallation eine brauchbare Konfiguration bereit. Die Runlevel 0 (Systemhalt) und 6 (Reboot) sollten in jeder Linuxdistribution einheitlich belegt sein. Runlevel 1 wird bei Debian, RedHat und SuSE (erst ab 7.3) ebenso einheitlich als Single User Mode konfiguriert. Darüber hinaus unterscheiden sich die Vorgehensweisen der Distributoren. Bei SuSe gab es ab Version 7.3 eine Änderung, so entspricht das Startverhalten der SuSE-Distribution dem von RedHat.

Runlevel Bedeutung
0 Systemhalt (engl. System halt)
S Einzelbenutzerbetrieb (engl. Single user mode); vom Bootprompt aus der US- Tastaturbelegung
1 Einzelbenutzerbetrieb
2 Lokaler Multiuserbetrieb ohne entferntes Netzwerk (engl. Local multiuser without remote network (e.g. NFS))
3 Voller Multiuserbetrieb mit Netzwerk (engl. Full multiuser with network)
4 Frei (engl. Not used)
5 Voller Multiuserbetrieb mit Netzwerk und KDM (Standard), GDM oder XDM (engl. Full multiuser with network and xdm)
6 Systemneustart (engl. System reboot)


Die Datei /etc/inittab

Wenn init mit seiner Arbeit beginnt, sucht es zunächst nach seiner Konfigurationsdatei /etc/inittab. Für den Fall, dass diese nicht existiert oder kein mit initdefault beginnender Eintrag enthalten ist, fordert init zur Eingabe des zu startenden Runlevels auf. Bei einer fehlenden Datei /etc/inittab ist nun nur der Start im Single User Modus (Runlevel 1, S bzw. s) zulässig, da zum Start im Multi-User Modus weitere Informationen benötigt werden, welche die Konfigurationsdatei enthält.

Im Single User Modus entnimmt init der Datei /etc/ioctl.save (sofern vorhanden, sonst gelten Default-Werte und die Datei wird erzeugt) die Einstellungen für das Terminal und startet das Programm /sbin/sulogin, das mit der bereits eröffneten Konsole /dev/console verbunden wird. In diesem Modus kann sich einzig der Systemverwalter anmelden, es laufen auch nur die zwingend benötigten Prozesse, so dass alle Ressourcen dem Administrator zur Verfügung stehen. Der Modus dient vorrangig der Pflege des Systems, so wäre es bspw. fatal, wenn ein Benutzer während der Reparatur des Dateisystems schreibenden Zugriff auf dieses erhielte. Im Falle des Multi User Modus kommt auf init eine Menge weiterer Arbeit zu.

In einem nächsten Schritt lässt init alle dem jeweiligen Runlevel zugeordneten Skripte von einem Shellskript namens rc starten. Das ist der Zeitpunkt, wenn die zahlreichen Meldungen über gestartete Dämonenprozesse über den Bildschirm flimmern. Ist das aktuelle Runlevel erreicht, startet init eine Reihe von getty-Prozessen, die wiederum auf der ihnen zugedachten Konsole das Kommando login ausführen, welches letztlich die Aufforderung zur Anmeldung auf den Bildschirm bringt.

Jede Zeile der zentralen Konfigurationsdatei des init-Prozesses besitzt folgenden Aufbau:

ID:Runlevel:Aktion:Prozess


Name Beschreibung  
ID Die ID ist eine fast beliebige, ein- bis vierstellige Zeichenfolge. Jede ID darf nur einmal vergeben sein und für Login- Prozesse ("getty") sollte sie der Nummer des Terminals entsprechen ("1" für "/dev/tty1").  
Runlevel Hier stehen alle Runlevel, für die die nachfolgende Aktion auszuführen ist. Da die Bezeichner eines Runlevels aus nur einem Zeichen bestehen, werden diese einfach hintereinander geschrieben. Dieses Feld wird ignoriert, wenn im Feld "Aktion" "sysinit", "boot", oder "bootwait" steht.  
Aktion Hier wird das »Wie« des Prozessstarts angegeben, die möglichen Einträge lauten:  
  respawn Sobald der Prozess endet, wird er von init erneut gestartet
  wait init wartet nach dem Start des Prozesses auf dessen Terminierung
  once Der Prozess wird nur einmal bei Erreichen des angegebenen Runlevels gestartet
  boot Der Prozess wird nur während des Bootvorganges ausgeführt
  bootwait Der Prozess wird nur während des Bootvorganges ausgeführt und init wartet auf dessen Terminierung
  off Der Prozess wird niemals gestartet
  ondemand Der Prozess wird gestartet, wenn das angegebene »ondemand«- Runlevel gerufen wurde. Diese Runlevel (a, b und c) können verwendet werden, um zusätzliche Dienste zu starten, ohne das aktuelle Runlevel zu beenden.
  initdefault Der Eintrag gibt das default- Runlevel an, das Prozessfeld wird ignoriert
  sysinit Falls ein solcher Eintrag existiert, wird der angegebene Prozess vor allen anderen gestartet. Typische Anwendung ist die Initialisierung von Komponenten, die in allen anderen Runleveln verfügbar sein sollen
  powerwait Der Prozess wird gestartet, wenn der Strom ausfällt (ist nur sinnvoll, wenn eine Notstromversorgung noch eine Zeitlang den Saft liefert), init wartet auf das Prozessende
  powerfail Wie »powerwait«, init wartet nicht auf das Prozessende
  powerokwait Wenn der Strom wieder anliegt, führt init diesen Prozess aus
  powerfailnow Falls die Notstromversorgung allmählich versagt, wird dieser Prozess noch aktiviert
  ctrlaltdel Das Verhalten beim »Affengriff« ([Ctrl]-[Alt]-[Del])
  kbrequest Wenn auf der Tastatur das vereinbarte Signal auftrat, wird der angegebene Prozess ins Leben gerufen
Prozess Das zu startende Skript oder Programm.  


Als erstes durchsucht init die Tabelle /etc/inittab nach einem Eintrag, dessen Aktion auf „sysinit“ steht. Ein solcher Eintrag dient in der Regel zur Erledigung der „Hausaufgaben“, wie dem Überprüfen und Mounten der Dateisysteme, setzen der Systemzeit, Initialisierung des Swap-Speichers, also Arbeiten, die für jedes Runlevel von Nöten sind.

si:I:bootwait:/etc/init.d/boot


boot und bootwait sind die folgenden Einträge, nach denen init die Datei durchforstet. Wie man sein System letztlich konfiguriert, ist Geschmackssache. Verwendet man ein einziges Skript, das die allgemeinen Einstellungen regelt, so spielt es keine Rolle, ob es mit einem sysinit-, oder bootwait-Eintrag in den Bootprozess eingebunden wird. Bei Verwendung mehrerer Skripte kann mit sysinit die Verarbeitung eines Skriptes vor den anderen erzwungen werden. Beide Einträge erfordern das Warten von init, bis die Prozesse ihre Tätigkeit abgeschlossen haben.

Der für den Administrator wohl interessanteste Eintrag ist die „initdefault“-Zeile, die Linux anweist, in einem konkreten Runlevel zu starten:

id:2:initdefault:


Der zweite Eintrag bestimmt dabei, das zu aktivierende Level. Entgegen den anderen Zeilen der Datei darf hier nur ein einziges Level angegeben werden. Möchte man permanent ein anderes Runlevel einrichten, so kann dieser Wert von Hand editiert oder mittels (distributionsspezifischer) Werkzeuge gesetzt werden: zB. SuSE: yast --> Administration des Systems --> Login.Konfiguration --> Login.Oberfläche (ein Wechsel ist nur zwischen Runlevel 2 und 3 möglich)

Für jeden von der Distribution definierten Runlevel muss ein Eintrag in der /etc/inittab vorhanden sein.

Hier ein Beispieleintrag, der betrifft das Runlevel 0, welches das Anhalten des Systems regelt. Erfolgt ein Wechsel zu diesem Runlevel, so wartet init auf das Ende des Skripts „rc“ (wait). „rc“ wird bei jedem Wechsel des Runlevels gerufen, als Argument wird ihm das neue Level übergeben. Die Einträge für alle weiteren Level sind analog aufgebaut. Um sinnvoll mit dem System arbeiten zu können, muss init noch für die Login-Konsolen Sorge tragen:

1:2345:respawn:/sbin/mingetty tty1


Wieder sei beispielhaft nur ein Eintrag für einen getty-Prozess auf der ersten Konsole erwähnt. Als Bezeichner (ID) empfiehlt das Manual zu inittab die Nummer des betreffenden Terminals. respawn besagt hier, dass nach dem Ableben des Prozesses (/sbin/mingetty) sofort ein Neuer zu starten ist. Das ist der Grund, warum nach einem logout eine neue Anmeldeaufforderung erscheint. Unter Linux wird dem normalen Benutzer häufig das Herunterfahren des Systems über den so genannten Affengriff gestattet. Die Reaktion des Systems auf diese Tastenkombination ([Ctrl]-[Alt]-[Del]) wird in der Datei /etc/inittab festgelegt:

ca::ctrlaltdel:/sbin/shutdown -r -t 4 now


Im Beispiel reagiert Linux nach 4 Sekunden Verzögerung mit einem Reboot.

Nach einer Modifikation der Datei /etc/inittab sollte der init-Prozess seine Konfigurationsdatei neu einlesen. telinit q überredet ihn hierzu.

Init-Skripte

Zahlreiche Skripte werden in verschiedenen Runleveln benötigt. Man denke nur an den Protokollanten von Linux, den syslogd, dessen Dienste eigentlich immer nützlich sein sollten. Um solche Init-Skripte nicht mehrfach im System speichern zu müssen, sammelt man alle in einem einzigen Verzeichnis. Dieses ist:
  • /sbin/init.d/rcx.d bei SuSE <= 7.0
  • /etc/rc.d/rcx.d bei SuSE ab 7.1
Jedes Skript, das nun in einem Runlevel zu starten ist, erscheint als Link unter zwei verschiedenen Namen im Verzeichnis des Runlevels. Dabei ist die Namensgebung der Verweise verbindlich und in unten stehender Abbildung skizziert.




Die Linknamen setzen sich aus drei Komponenten zusammen, die das Skript rc bewertet:
  • Der erste Buchstabe beschreibt, ob es ein Stoppskript (Buchstabe = K) oder ein Startskript (Buchstabe = S) ist.
  • Zwei Ziffern bestimmen die Priorität des Skriptes (00 bis 99). Von den Skripten in einem Runlevel werden alle mit kleinerer Nummer vor den Skripten mit höherer Nummer abgearbeitet, somit wird sicher gestellt, dass ein Dienst, der einen anderen zu seiner Arbeit bedingt, erst nach diesem aktiviert wird. Skripte mit identischer Nummer sind voneinander unabhängig und werden entsprechend ihrer alphabetischen Ordnung betrachtet.
  • Der Rest ist der „eigentliche“ Name und kann beliebig gewählt werden. Normal wird man sich für einen Namen entscheiden, der auf das entsprechende Skript schließen lässt.
Hier sieht man den init-Prozess mit den gestarteten Unterprozessen (Parent- und Children-Prozesse). Der init-Prozess hat die Prozess-ID 1. Die Prozess-ID 0 ist in entweder der Kernel, der Scheduler, oder er wird nicht verwendet.

fladung@linux-sf:/ # pstree -p
init(1)-+-acpid(1277)
|-bdflush(5)
|-cron(1733)
|-cupsd(1426)
|-kdm(1839)-+-X(1891)
|-kdm(1892)---kdm_greet(1908)
|-keventd(2)
|-khubd(963)
|-kinoded(7)
|-klogd(903)
|-knodemgrd_0(937)
|-kreiserfsd(13)
|-ksoftirqd_CPU0(3)
|-kswapd(4)
|-kupdated(6)
|-lvm-mpd(374)
|-master(1577)-+-pickup(2300)
|-qmgr(1644)
|-mdrecoveryd(8)
|-mingetty(1894)
|-mingetty(1895)
|-mingetty(1896)
|-mingetty(1897)
|-mingetty(1898)
|-mingetty(1899)
|-nscd(1735)---nscd(1736)-+-nscd(1737)
|-nscd(1738)
|-nscd(1739)
|-nscd(1740)
|-nscd(1741)
|-portmap(1148)
|-resmgrd(1112)
|-sshd(1278)---sshd(2021)---bash(2022)---su(2175)---bash(2176)---pstree+
|-syslogd(900) |-xinetd(1742)


Administration von Prozessen

Befehl: nohup

Aufruf: nohup Befehl

Normalerweise wird ein Programm von einer Shell aufgerufen. Die Shell startet dann einen weiteren Prozess, dessen Elternprozess sie selbst darstellt. Wenn die Shell jetzt beendet wird, etwa durch ein exit, wird der neu gestartete Befehl dadurch automatisch auch beendet. In manchen Fällen kann es jedoch auch gewünscht sein, dass ein Prozess auch nach dem Abmelden weiterläuft. Diese Möglichkeit bietet uns das Programm nohup. Es startet einen Befehl und ignoriert dann das Hangup-Signal (SIGHUP) für diesen Prozess. Dieses Signal wird gewöhnlich beim Abmelden an alle Prozesse gesendet, um ihnen mitzuteilen, dass die Sitzung jetzt geschlossen wird.

Die Ausgaben von nohup werden ggf. in eine Datei nohup.out umgeleitet. Kann diese im aktuellen Verzeichnis nicht erzeugt werden, wird sie im Heimatverzeichnis angelegt. Scheitert auch dies, beendet nohup seine Tätigkeit. Ein über nohup gestartetes Kommando erhält eine um 5 erhöhte Priorität.

Befehl: ps

Aufruf: ps [-options]

Das Programm ps bietet einen Schnappschuss der gerade laufenden Prozesse. Es zeigt verschiedene Daten dieser Prozesse an, das wichtigste ist dabei die Prozess-ID (PID) des jeweiligen Prozesses. Ohne Parameter aufgerufen zeigt ps nur die eigenen Prozesse.
Über Optionen lassen sich zum einen die anzuzeigenden Prozesse selektieren und zum anderen das Ausgabeformat steuern. Wichtige Optionen zur Auswahl der Prozesse sind:

Optionen Bedeutung
-A oder -e Wirklich alle Prozesse anzeigen
-a Alle Prozesse anzeigen, die ein Terminal kontrollieren
-U bzw. -G Auswahl nach UID bzw. GID
-p Nur den angegebenen Prozess (PID ist anzugeben)
-r Nur laufende Prozesse
-x Auch Prozesse anzeigen, die kein Terminal kontrollieren
-f Prozesshierarchie als Baum anzeigen
-l Langformat
-e Anzeige der Umgebungsvariablen des Prozesses


fladung@linux-sf:~> ps
PID TTY TIME CMD
2200 pts/1 00:00:00 bash
4551 pts/1 00:00:00 ping
5086 pts/1 00:00:00 ps
fladung@linux-sf:~> ps -p 4956 -l
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 500 4956 4630 0 78 0 - 575 schedu pts/3 00:00:00 sleep
fladung@linux-sf:~> ps -x -f
PID TTY STAT TIME COMMAND
4630 pts/3 S 0:00 -bash
4956 pts/3 S 0:00 \_ sleep 4000


Befehl: pstree

Aufruf: pstree [-options]

Das Kommando stellt die aktiven Prozesse in einer Baumstruktur dar, welche die Prozessvererbung symbolisiert.

fladung@linux-sf:~> pstree
init-+-acpid
|-bdflush
|-cron
|-cupsd
|-httpd2-prefork---6*[httpd2-prefork]
|-kalarmd
|-kamix
|-kdeinit-+-artsd
|-5*[kdeinit]
|-8*[kdeinit]
|-kdeinit---kdesktop_lock
|-kdm-+-X
|-kdm---kde-+-kwrapper
|-ssh-agent


Befehl: kill

Aufruf: kill [-Signal] PID

Mit dem Kommando lassen sich Signale an Prozesse versenden. Die Angabe der Prozesse erfordert deren Prozessnummer (PID) oder die Jobnummer (%n). Fehlt die Angabe des Signals, wird Signal 15 (SIGTERM) angenommen.

Die gebräuchlichsten Signale sind dabei 1 (SIGHUP), das vor allem verwendet wird, um Prozesse zum erneuten Einlesen ihrer Konfigurationsdateien zu zwingen, 15 (SIGTERM), das einer höflichen Aufforderung an einen Prozess gleichkommt, er solle doch seine Arbeit beenden (ein Prozess kann dieses Signal ignorieren) und 9 (SIGKILL), das für den betreffenden Prozess das sofortige Ende bedeutet.

fladung@linux-sf:~> kill -9 4860
[1]+ Getötet sleep 3000
fladung@linux-sf:~>


Befehl: killall

Aufruf: kill [-Signal] PID

Der wesentlichste Unterschied zum Kommando kill ist die Spezifizierung der Prozesse über den Namen der Kommandos, die sie ausführen oder mittels ihrer Gruppennummer (-g GID). killall sendet allen Prozessen Signale, die das Kommando ausführen, mit der Option -i kann aber eine nochmalige Rückfrage vor dem tatsächlichen Senden erzwungen werden:

fladung@linux-sf:~> killall -i sleep
sleep(4698) abbrechen? (y/n) y
sleep(4815) abbrechen? (y/n) y
sleep(4816) abbrechen? (y/n) y
[1] Beendet sleep 5000
[2] Beendet sleep 5000
[3] Beendet sleep 5000
fladung@linux-sf:~>


Befehl: nice

Aufruf: nice [OPTION]...

Bei Problemen mit der Leistung, ist die CPU-Auslastung üblicherweise der erste Faktor, der betrachtet wird.

In Linux werden priotätsbasiertes Scheduling für die Zuteilung der CPU-Ressourcen zwischen mehreren miteinander konkurierenden Prozessen vergeben. Jedesmal wenn der CPU frei wird, wählt der Scheduler den favorisierten Prozess aus und beginnt mit seiner Ausführung bzw. setzt ihn fort. Üblicherweise entspricht dies den Prozess mit der niedrigeren Zahl bei den typischen Implementierungen als höher favorisiert eingestuft werden. Der Nice-Wert liegt im Bereich zwischen -20 und 20, wobei -20 die höchste Priorität darstellt. (Die Standardpriorität ist 0.) Nur root kann den Nice-Werte festlegen, die unter dem Standardwert liegen.

Befehl: renice

Aufruf: renice [OPTION]...

Prozessen kann mittels renice nachträglich eine andere Priorität zugeteilt werden. Wie auch bei nice gilt, dass einzig Root die Priorität erhöhen darf:

Optionen Bedeutung
-p Prozess-ID
-g GID Die Gruppennummer von Prozessen
-u User


fladung@linux-sf:~> renice +1 -u fladung
500: Alte Priorität: 0, neue Priorität: 1
fladung@linux-sf:~>


Befehl: top

Aufruf: top [OPTION]...

top listet Prozesse, sortiert nach ihrem Anteil an CPU-Zeit, auf. Nach Voreinstellung wird diese Liste alle 5 Sekunden aktualisiert: Mit der Option „-d Zeit“ kann ein anderes Intervall eingestellt werden. Mit der Option „-n Anzahl“ kann die Anzahl der Refreshs eingeschränkt werden. Anschließend wird top seine Arbeit beenden.

Die ersten fünf Zeilen zeigen allgemeine Systeminformationen (wie der Befehl uptime):
  • wie lange das System schon läuft
  • Statistiken zur Gesammtzahl der Prozesse und die aktuelle Auslastung von dem CPU
  • Speicher und Swap Bereich
Der Rest der Ausgabe ist ähnlich, wie mit den verschiedenen Optionen von ps zu erreichen ist, wobei die Prozesse nach der aktuellen CPU-Verbrauch sortiert sind.

top - 14:52:42 up 3:53, 5 users, load average: 0.00, 0.03, 0.01
Tasks: 95 total, 1 running, 83 sleeping, 11 stopped, 0 zombie
Cpu(s): 0.0% user, 0.3% system, 0.0% nice, 99.7% idle
Mem: 514716k total, 321384k used, 193332k free, 64592k buffers
Swap: 1036152k total, 0k used, 1036152k free, 149760k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2988 root 16 0 952 952 748 R 0.7 0.2 0:00.11 top
1 root 15 0 256 256 220 S 0.0 0.0 0:04.93 init
2 root 15 0 0 0 0 S 0.0 0.0 0:00.03 keventd
3 root 34 19 0 0 0 S 0.0 0.0 0:00.02 ksoftirqd_CPU0
4 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kswapd
5 root 25 0 0 0 0 S 0.0 0.0 0:00.00 bdflush
6 root 15 0 0 0 0 S 0.0 0.0 0:00.07 kupdated


Arbeiten mit dem Befehl top

Während das Kommando in periodischen Abständen das Terminal mit neuen Informationen überschwemmt, lassen sich verschiedenste Aktionen vornehmen. Folgende Eingaben (Auswahl) bewirken folgende Reaktion:

Optionen Bedeutung
[Leertaste] Sofortige Aktualisierung der Anzeige
f Hierüber kann die Anzeige der Informationen eingestellt werden. Es erscheint eine Auflistung aller Informationsfelder, wobei ausgewählte Felder mit einem Stern * gekennzeichnet sind. Vor jedem Feld steht ein Bezeichner (Buchstabe), durch dessen Eingabe die Auswahl umgeschalten wird. Rückkehr zur Ausgabe von top durch [Enter].
k Zum Senden von Signalen an einen Prozess. Es wird zur Angabe der PID und des zu sendenden Signals aufgefordert.
n Zum Ändern der Anzahl angezeigter Prozesse. Man wird zur Eingabe der neuen Anzeige aufgefordert.
o Zeile der erscheinenden Ausgabe ist die Reihenfolge symbolisch dargestellt, wobei ein gewähltes Feld durch einen Großbuchstaben markiert ist. Durch Eingabe des entsprechenden Feldbezeichners als Kleinbuchstabe, wird der Eintrag in der Liste "nach hinten" befördert; mittels des Großbuchstaben nach vorn. Rückkehr zur Ausgabe von top durch [Enter].


Fazit

Die Möglichkeit der Überwachung und Steuerung von Prozessen unter Linux-Systemen ist von wichtiger Bedeutung. Programme wie ps, top, kill und renice ermöglichen zu sehen, was ein Prozess gerade macht, und ihn zu steuern. Je mehr man über jeden einzelnen ablaufenden Prozess weiß, desto leichter ist es, Probleme herauszufinden, wenn sie sich einschleichen. In einem System treten gewöhnlich Probleme wie Langsamkeit oder Instabilität aus bestimmten Gründen auf. Mit dem beschrieben Tools lassen sich diese Probleme beseitigen.

Quellen
  • Aleen Frisch, Unix System Administration O´Reilly Verlag 2003
  • Thomas Ermer und Michael Meyer, Die Linuxfibel GFDL (GNU Free Documentation License), Version 0.8.2 http://www.linuxfibel.de
  • SuSE Linux AG, Suse Linux 8.2 Administrationshandbuch, 5. Auflage Nürnberg 2003
  • Linux man pages (ps, pstree, top, kill, killall, nice, renice)


dreamer
Expert
Beitrag vom:
14-09-2007, 21:46:16

Die Informationen werden sehr deutlich und detailliert dargestellt. Mehr davon!

-----------------------------------------------------


[back to top]



Userdaten
User nicht eingeloggt

Gesamtranking
Werbung
Datenbankstand
Autoren:04508
Artikel:00815
Glossar:04116
News:13565
Userbeiträge:16552
Queueeinträge:06246
News Umfrage
Ihre Anforderungen an ein Online-Zeiterfassungs-Produkt?
Mobile Nutzung möglich (Ipone, Android)
Externe API Schnittstelle/Plugins dritter
Zeiterfassung meiner Mitarbeiter
Exportieren in CSV/XLS
Siehe Kommentar



[Results] | [Archiv] Votes: 1154
Comments: 0