Open Source im professionellen Einsatz

Aus dem Nähkästchen geplaudert: Daemons

Die Geister, die ich rief

Die Liste laufender Prozesse eines scheinbar untätigen Unix-Systems ist für frisch gebackene Administratoren überraschend. Klar, dass jeder Dienst und jeder Prozess eine Aufgabe erfüllt. Diese Folge des Admin-Workshops erklärt, wofür die einzelnen Daemons zuständig sind.

Der Workshop in Heft 9/04[1] stellte Methoden vor, mit denen der interessierte Administrator die aktuell laufenden Dienste aufspürt. Damit weiß er aber noch nicht, wozu diese Dienste gut sind. Neben spannenden Entdeckungen in den Tiefen der Linux-Maschinerie beschert das Wissen über die wichtigen Daemons auch einen Sicherheitsvorteil: Die Kenntnis der Software, die auf einem typischen Linux-Server läuft, erlaubt das Erkennen fremder und potenziell gefährlicher Software.

Abbildung 1 zeigt ein Beispiel für die zahlreichen Prozesse, die Linux-Nutzer auf ihrem Rechner (hier eine nicht mehr ganz taufrische Suse-8.2-Installation) antreffen. Das Beispielsystem ist eine abgespeckte Workstation, bei der die meisten Netzwerkdienste deaktiviert sind - in einem voll ausgebauten Server spuken deutlich mehr Dämonen.

Abbildung 1: Das Kommando »ps ax« zeigt die laufenden Prozesse einer frisch gebooteten Suse 8.2 (hier gekürzt). Kernel-Threads sind an den eckigen Klammern erkennbar.

Abbildung 1: Das Kommando »ps ax« zeigt die laufenden Prozesse einer frisch gebooteten Suse 8.2 (hier gekürzt). Kernel-Threads sind an den eckigen Klammern erkennbar.

Die nach dem Booten anzutreffenden Prozesse gehören zwei Gruppen an: Unter Linux sind die so genannten Kernel-Threads von User-Prozessen zu unterscheiden. Erstere arbeiten im Kernelspace, im geheiligten Adressraum von Linux. Kernel-Threads entstehen in der Regel bei der Initialisierung von Modulen. User-Prozesse hingegen sind gewöhnliche Benutzerprozesse, die zum Beispiel durch den Aufruf eines Programms oder durch »fork()« entstehen.

Aller Anfang ist Init

Der »init«-Prozess (PID 1) ist die Mutter aller Prozesse. Wie in[2] beschrieben sorgt er dafür, dass ein Linux-System stets in einem angemessenen Betriebszustand arbeitet. Dazu startet und beendet Init andere Programme gemäß den Angaben in der Konfigurationsdatei »/etc/inittab«.

Kernel-Threads[4] sind an den eckigen Klammern um den Prozessnamen zu erkennen. Sie kümmern sich um essenzielle Arbeiten für den Kernel. Typische Beispiele für einen Linux-Kernel der 2.4er Reihe sind in Tabelle 1 zu sehen. Weitere Kernel-Threads sorgen für die Verwaltung von logischen Geräten (»mdrecoveryd« oder »raid*d«) oder spezieller Hardware (»ahd*« und »scsi*« oder »khubd«).

Tabelle 1:
Kernel-Threads

 

Thread

Erläuterung

keventd

Hilft bei der Verwaltung von Kernel-Threads selbst.

kapmd, kacpid

Kümmern sich um die Interaktion mit dem Powermanagement
des Computers (Advanced Power Management oder Advanced
Configuration and Power Interface).

ksoftirqd

Sorgt für die Performance-freundliche Abarbeitung von
Interrupts (Soft-IRQs). Möglicherweise existiert dieser
Prozess unter verschiedenen Namen für die einzelnen
Prozessoren.

pdflush, bdflush, kupdated, kjournald

Stellen sicher, dass auf Festplatte geschriebene Daten auch
tatsächlich auf der Magnetschicht ankommen.

kswapd, kscand

Verlagern die zum jeweiligen Zeitpunkt nicht benötigten
Daten aus dem Hauptspeicher auf die Festplatte.

Kernel-Threads entstehen, wenn sich die entsprechende Stelle des Kernels initialisiert, in der Regel also recht früh während des Bootvorgangs. Ausnahmen sind Module, die erst wesentlich später nachgeladen werden, zum Beispiel als Reaktion auf ein neu eingestecktes USB- oder Cardbus-Gerät. Im Gegensatz dazu werden die User-Prozesse erst nach und nach über die von »init« gestartete Programmkaskade aufgerufen. Das kann einige Minuten dauern und führt fast ausnahmslos zu höheren Prozess-IDs.

Ab ins Netz

Computer in professionellen Netzwerken müssen als eine der ersten Funktionen ihren Netzzugang einrichten. Meist liegen die erforderlichen Konfigurationsdaten nicht auf dem Endgerät, sondern eine Zentrale verteilt die Parameter über einen Mechanismus wie DHCP (Dynamic Host Configuration Protocol). In diesem Fall ist einer der frühesten User-Prozesse »dhcpcd« (DHCP Client Daemon), er hat auf dem Testsystem die PID 615. Achtung: Das zweite c vor dem d unterscheidet den Client- vom Server-Daemon »dhcpd«.

Der DHCP-Client besorgt essenzielle Daten wie die eigene IP-Adresse, Informationen über die Netzmaske sowie das Gateway und trägt diese Daten in die Routingtabellen des Kernels ein. Der Client aktualisiert die Parameter auch, wenn der DHCP-Server eine Änderung verlangt. Statt »dhcpcd« ist manchmal noch »pump« zu finden, die ältere Version eines DHCP-Clients mit fast identischen Aufgaben.

Privat genutzte Geräte, deren DSL- oder Kabel-Zugang ins Internet über einen separaten Router läuft, benötigen normalerweise ebenfalls einen »dhcpcd«. Wer ein manuell konfiguriertes LAN verwendet, sieht dagegen keinen eigenen DHCP-Prozess, da er die Konfigurationsdaten lokal speichert.

Modem- oder ISDN-Verbindungen nutzen heute fast immer das Point-to-Point-Protokoll mit einem Daemon namens »pppd«, den viele Anwender aus Kostengründen nur manuell starten. Direkte DSL-Anbindungen, bei denen der Linux-Computer das DSL-Modem über seine Ethernet-Karte ansteuert, verwenden entweder »dhcpcd« oder - in Deutschland häufiger - »pppd« in Verbindung mit »pppoe« (PPP over Ethernet).

Diesen Artikel als PDF kaufen

Als digitales Abo

Als PDF im Abo bestellen

comments powered by Disqus

Ausgabe 07/2013

Preis € 6,40

Insecurity Bulletin

Insecurity Bulletin

Im Insecurity Bulletin widmet sich Mark Vogelsberger aktuellen Sicherheitslücken sowie Hintergründen und Security-Grundlagen. mehr...

Linux-Magazin auf Facebook