Komplizierte Organismen, wie Linux-Systeme es nun einmal sind, haben so ihre ganz eigenen Wehwehchen. Dr. Linux beobachtet die Patienten in den Linux-Newsgruppen, stellt Rezepte für aktuelle Probleme aus und alternative Heilmethoden vor.

Prüfungsstress

Wenn ich mein Linux hoch fahre, kommt immer mal wieder die Meldung:

/dev/Laufwerk has reached maximal mount count, check forced.

Kann ich die Häufigkeit der Überprüfungen meines Dateisystems beeinflussen?

Dr. Linux: Die Überprüfung eines Linux-ext2-Dateisystems erfolgt in der Regel bei jedem zwanzigsten Boot-Vorgang. Das Intervall lässt sich mit /sbin/tune2fs verändern.

Um einen entsprechenden Befehl auf der Kommandozeile abzusetzen, müssen Sie wissen, auf welcher Partition das jeweilige Dateisystem liegt (siehe Kasten “Partitionen”.

Dies erfahren Sie bei automatisch eingebundenen Datenträgern, indem Sie den Befehl mount ohne weitere Optionen eingeben. Wenn Sie nur eine Linux-Partition haben, “hängt” am Wurzelverzeichnis / das einzige “echte” Dateisystem in Ihrer Auflistung:

user$ mount/dev/hda6 on / type ext2 (rw)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=0620)

Welche Partition automatisch wo eingehängt wird, legen Sie in der Datei /etc/fstab (“Filesystemtabelle”) fest. Hier ist das Wurzelverzeichnis (“Root-Directory”) mit dem Dateisystem ebenfalls aufgeführt:

/dev/hda5   swap     swap      defaults   0  0/dev/hda6 / ext2 defaults 1 1
/dev/hdc    /cdrom   iso9660   ro,noauto,user,exec 0  0

In diesem Beispiel befindet sich das Root-Dateisystem ganz eindeutig auf /dev/hda6. Der Befehl zur Änderung der entsprechenden Prüfintervalle könnte also folgendermaßen aussehen:

root# tune2fs -c 5 /dev/hda6

Mit der Option -c stellt tune2fs die maximalen Mounts ein, die zwischen zwei Dateisystemprüfungen liegen dürfen. Die Ziffer 5 bestimmt die Boot-Vorgänge bis zur nächsten Prüfung; in diesem Beispiel würde das System künftig bei jedem fünften Booten überprüft.

tune2fs bestätigt die Ausführung des Befehls freundlicherweise:

tune2fs 1.17, 26-Oct-1999 for EXT2 FS 0.5b, 95/08/09
Setting maximal mount count to 5

Wurde Ihr System nicht ordnungsgemäß herunter gefahren (z. B. bei einem Stromausfall), erfolgt eine automatische Prüfung des Dateisystems auch dann, wenn Sie das Intervall der Systemprüfung mit tune2fs auf 0 gesetzt haben. Denn zusätzlich zur Anzahl der maximalen Mounts, die mit tune2fs festgelegt werden, wird im Superblock eines ext2-Dateisystems das Valid-Bit gespeichert.

Beim Hochfahren des System wird dieses vom Programm e2fsck geprüft. Ist es auf 0 gesetzt, versucht e2fsck zu retten, was zu retten ist, indem es eine automatische Reparatur des Dateisystems auf den Weg bringt. Bevor Sie nun die Prüfungen Ihres Systems mit tune2fs ganz abstellen, sollten Sie darüber informiert sein, was fsck und e2fsck leisten, bzw. welche Reparaturen ggf. gemacht werden.

• Zunächst erfolgt ein Vergleich der Informationen im Superblock mit dem aktuellen Zustand des Systems.
• Es wird geprüft, ob jeder Inode-Eintrag gültig ist und einem Verzeichniseintrag zugeordnet werden kann.
• Dann wird nachgesehen, ob für alle Dateien die zugehörigen Datenblöcke existieren und eindeutig sind.
• Die Link-Anzahl in allen Verzeichnissen wird mit dem internen Link-Zähler im Inode verglichen.
• Schließlich erfolgt die Prüfung, ob die Gesamtzahl aller Blöcke gleich der Anzahl belegter plus freier Blöcke ist.

Vielleicht stellte sich beim Lesen dieser Zeilen ein Gefühl von Desinteresse, Ödnis oder Sekundenschlaf ein, vielleicht finden Sie das alles furchtbar theoretisch, langweilig und uninteressant – immerhin könnte dies ein Grund sein, die Überprüfungen des Dateisystems auch weiterhin regelmäßig Linux zu überlassen.

Ein weiterer ist, dass Sie eine Überprüfung des Dateisystems nicht einfach “mal eben” starten können. Ist die Partition schreibbar gemountet, darf kein Dateisystemcheck erfolgen. Auch Ihr System prüft das Wurzelverzeichnis nur im Modus mit “Leseberechtigung”. Das können Sie beim Systemstart leicht beobachten:

[...]
Partition check:
 hda: hda1 hda3 < hda5 hda6 >
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 60k freed
INIT: version 2.76 booting
Running /sbin/init.d/boot
Mounting /proc device                                                 done
Activating swap-devices in /etc/fstab...
Adding Swap: 128484k swap-space (priority -1)                         done
Checking file systems...
Parallelizing fsck version 1.17 (26-Oct-1999)
/dev/hda6: clean, 139696/1038336 files, 2225322/4152771 blocks        done
Mounting local file systems...[...]

Erst danach werden die Partitionen “vollständig”, also les- und beschreibbar, im System eingehängt. Alle Fachbücher zu und über Linux weisen darauf hin, dass die Benutzerin ihr System erst dann “von Hand” prüfen soll, wenn Sie die Manpages zu tune2fs und e2fsck gelesen und verstanden hat. Dieser Meinung kann sich die Artikelschreiberin nur anschließen.

Fundbüro

In meinem System habe ich das Verzeichnis lost+found gefunden. Darin ist aber nichts installiert, wofür ist dann es gedacht?

Dr. Linux: Ein Verzeichnis namens lost+found befindet sich auf allen ext2-Dateisystemen. Hierhin werden Dateien verschoben, die bei einer Dateisystemprüfung “durchgefallen” sind. Damit haben Sie die Möglichkeit, kaputte Dateien zumindest teilweise zu retten.

Zum Beispiel kann der Verzeichniseintrag einer Datei fehlen, ihr Inhalt aber noch vorhanden sein. Solche Fehler im Dateisystem entstehen durch nicht ordnungsgemäßes Herunterfahren des Systems, wie es ein Stromausfall oder versehentliches Drücken der Reset-Taste nach sich ziehen.

Heinzelmännchen

Es kommt bei mir mit einer gewissen Regelmäßigkeit vor, dass die Festplatte auf einmal anfängt zu arbeiten. Mit top habe ich festgestellt, welche Prozesse da laufen. Unter anderem sind das find und mandb. Was mich dabei irritiert ist, dass root offensichtlich automatische Aktionen ausführt, während ich gar nicht als root eingelogt bin.

Zudem stört mich, dass mitten in der Nacht die Festplatte wegen eines find-Prozesses rödelt (was logisch ist, da etwas gesucht wird). Nun meine Frage: Wo kann ich diese automatischen Prozesse steuern, sprich: Wie kann ich sie ändern bzw. löschen? Haben diese Prozesse einen Sinn?

Dr. Linux: Solche automatischen Prozesse werden durch das Programm crond (oft auch nur cron genannt) ausgeführt.

Dieser Cron-Daemon ist ein Programm, das beim Booten des Systems durch das cron(d)-, manchmal auch cron.init-Initialisierungsskript im Verzeichnis /etc/rc.d/init.d, /etc/init.d oder auch /sbin/init.d gestartet wird. Wenn Sie den Ursprung Ihres Daemons tatsächlich genau herausfinden möchten, geben Sie den Befehl

root# locate cron

auf einer Kommandozeile ein. Sollten Sie zu viele Treffer landen, finden Sie auf einer grafischen Oberfläche an den zur Verfügung stehenden Terminalfenstern meist einen Rollbalken, der die Durchsicht aller Verzeichnisse und Dateien, die Ihnen der Suchbegriff liefert, erleichtert.

Das cron(d)-Programm läuft – wie alle Daemonen – im Hintergrund und überprüft bestimmte Dateien des Systems, ob dort Aufträge hinterlegt sind, die zu festgelegten Zeiten ausgeführt werden sollen. Schauen Sie in Ihr Verzeichnis /etc. Dort finden Sie die /etc/crontab(elle), auch System-crontab genannt, und zumeist folgende Verzeichnisse:

• cron.daily: Hier sind die ausführbaren Skripte für tägliche Aufgaben hinterlegt.
• cron.hourly: In diesem Verzeichnis liegen Skripte für Aufgaben, die stündlich abgearbeitet werden sollen.
• cron.weekly: Skripte wöchentlich durchzuführender Aufgaben werden hier abgelegt.
• cron.monthly: Ablage für Skripte, die monatlich auszuführende Aufträge enthalten. Die Aufgaben oder Cron-jobs darin werden zu den in der /etc/crontab angegebenen Zeiten ausgeführt. Dabei unterscheidet sich die /etc/crontab eines SuSE-Linux von der einer Red-Hat-Linux-Distribution schon auf den ersten Blick ganz erheblich.

Beispielsweise sieht die /etc/crontab bei SuSE 6.3 in Auszügen so aus:

# check scripts in cron.hourly, cron.daily, cron.weekly and cron.monthly
#
-*/15 * * * *   root  test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons
0 0  * * *     root  rm -f /var/cron/lastrun/cron.daily
0 0  * * 6     root  rm -f /var/cron/lastrun/cron.weekly
0 0  1 * *     root  rm -f /var/cron/lastrun/cron.monthly

… wohingegen die /etc/crontab bei Red Hat folgende Einträge hat:

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

Werfen wir einen Blick auf das Format einer /etc/crontab mit all den rätselhaften Sternchen und Ziffern.

Jede Zeile ist in drei Bereiche gegliedert: wann, wer, was. Im “Wann-Bereich” werden jeweils durch Leerzeichen getrennt die Zeitangaben in der Reihenfolge Minute(n), Stunde(n), Tag, Monat, Wochentag gesetzt. Ein * steht für jeden möglichen Wert in diesem Feld.

Erlaubt sind

• die Minuten 0–59 sowie *. Ein Eintrag wie 0-59/15 * * * * bewirkt, dass alle 15 Minuten der nachfolgend gesetzte Befehl ausgeführt wird.
• die Stunden 0–23 und *. Auch hier können Sie Bereiche angeben: 0 13-18 * * * * hat zur Folge, dass jede volle Stunde zwischen 13 und 18 Uhr der nachfolgende Befehl ausgeführt wird. 0 10,12,16 * * * * hingegen führt den passenden Cronjob zur vollen Stunde um 10, 12 und 16 Uhr aus.
• die Monatstage 0–31 und *. 15 12 6,20 * * steht für den 6. und 20. eines jeden Monats um Viertel nach 12.
• die Monate 1–12 und * sowie
• die Wochentage 0–7 und *, wobei der Sonntag sowohl durch die 0 als auch die 7 gekennzeichnet werden kann.

Als aufmerksamer Mensch, der sich mit crontab beschäftigen möchte, haben Sie bemerkt, dass das – zu Beginn der zitierten SuSE-crontab soeben nicht erklärt wurde. Wenn Sie eine andere Distribution benutzen, haben Sie vielleicht schon verzweifelt und ergebnislos in der Ausgabe von man 5 crontab danach gesucht. Kein Wunder, denn auf den meisten Unix- und Linux-Systemen ist dies ein ungültiger Eintrag. In der SuSE-Manpage zu crontab(5) finden Sie jedoch mit

Wenn die UserID des Besitzers 0 ist,
kann er als erstes Zeichen eines
crontab-Eintrags ein  "-" setzen.
cron wird dann im Syslog keine Meldung
über dieses Kommando veranlassen.

auf Seite 3 die Erklärung und noch weitere Einzelheiten, wie Sie die Flexibilität von cron(d)s-Zeiteinträgen für sich nutzen können.

Im “Wer-Bereich” der Systemcrontab steht, durch Leerzeichen vom “Wann-Bereich” getrennt, der Name des Anwenders, in dessen Namen der Cronjob ausgeführt wird.

Wieder durch Leerzeichen abgetrennt, beginnt der “Was-Bereich”. Wenn Sie z. B. mit dem Programm fetchnews Ihre News (siehe Kasten “News”) auf Ihren lokalen News-Server herunter laden wollen, tragen Sie am besten den vollständigen Pfad zum Befehl ein; auf meinem System ist das /usr/sbin/fetchnews.

Ein fertiger Eintrag in der /etc/crontab, der bewirkt, dass der Benutzer news an den Tagen Montag bis Freitag um 20.00 Uhr News-Beiträge abholt, sieht dann so aus:

0 20 * * 1-5   news  /usr/sbin/fetchnews -vv

Beachten Sie, dass der angeführte Benutzer die Berechtigung haben muss, den ihm zugeordneten Befehl auch auszuführen.

Sollte keine Netzverbindung zum vorgemerkten Zeitpunkt bestehen, schickt cron Ihnen eine Mail:

Date: Sun, 2 Jul 2000 11:00:01 +0200
From: Cron Daemon <root@max.de>
To: root@max.de
Subject: Cron <news@max>  /usr/sbin/fetchnews -vv
1.9.4: verbosity level is 2
Trying to connect to News.CIS.DFN.DE ... failed.

Aber auch eine Erfolgsmeldung wird zugestellt:

Date: Sun, 2 Jul 2000 13:00:03 +0200
From: Cron Daemon <root@max.de>
To: root@max.de
Subject: Cron <news@max>  /usr/sbin/fetchnews -vv
1.9.4: verbosity level is 2
Trying to connect to News.CIS.DFN.DE ... connected.
Getting new newsgroups from News.CIS.DFN.DE
Read server info from /var/spool/news/leaf.node/News.CIS.DFN.DE
de.comp.os.unix.linux.newusers: considering articles 128807-128875
de.comp.os.unix.linux.newusers: 69 articles fetched, 0 killed[...]
Disconnected from News.CIS.DFN.DE.

In jedem Fall können Sie in den ausführbaren Skripten im Verzeichnis /etc/cron.daily nachlesen, welche “automatischen Prozesse” Ihre Festplatte täglich zum “Rödeln” bringen. Die Berechtigung zum Lesen dieser Dateien hat auf den meisten Systemen nur root.

Bei einer Eingabe von

user$ top

auf einer Befehlszeile, während die Cronjobs laufen, können Sie verfolgen, welche Prozesse gestartet und beendet werden. Je nach System und Einstellungen werden Sie einige der folgenden Aktionen beobachten:

• mandb erneuert die Manpage-Datenbank.
• Das Verzeichnis /tmp wird entleert.
• updatedb aktualisiert die Datenbank, auf die das Suchkommando locate zugreift. locate arbeitet ähnlich wie find, nur schneller, weil es auf eine Datenbank zugreift und das System nicht direkt untersucht. Um ein korrektes Ergebnis von Suchanfragen zu erhalten, muss diese Datenbank aktuell sein.
• Die log(buch)-Dateien werden gepflegt, damit sie nicht ins Unendliche wachsen.

Abhängig vom System und seinen Sicherheitseinstellungen werden die für Sie (vor)konfigurierten Cronjobs vom Benutzer root oder nobody ausgeführt.

Herr der Zeiten

Gibt es keine einfachere Möglichkeit, die Systemcrontab zu editieren?

Dr. Linux: Wenn Sie linuxconf benutzen, haben Sie beim Unterpunkt System/Cron jobs von root die Möglichkeit, neue Aufgaben einzufügen (Abbildung 1). Wählen Sie crond aus der Liste in System/Dienste aus (Abbildung 2, oben), so können Sie den Cron-Daemon auch komplett deaktivieren (Abbildung 2, unten).

Abbildung 1: Cron-jobs für root mit linuxconf einrichten

Letzteres ist – unabhängig von einer bestimmten Distribution – ratsam, wenn Sie Linux auf einem Laptop im Batteriebetrieb betreiben oder während des Brennens von CDs.

Bei SuSE wird selbstverständlich auch Cron mit Yast konfiguriert.

Abbildung 3: Die Einstellungen für Cron zu finden, ist nicht so ganz einfach…

Abbildung 4: So konfigurieren Sie die Skripte in cron.daily mit Yast

Abbildung 4 zeigt, wo Sie die Einstellungen unter SuSE Linux mit yast ändern können: Wählen Sie nach Administration des Systems den Eintrag Konfigurationsdatei verändern (Abbildung 3).

Dort bestimmen Sie, welche Aufgaben die Skripte im Verzeichnis /etc/cron.daily abarbeiten sollen:

• CRON: Hier legen Sie grundsätzlich fest, ob der Cron-Daemon aktiviert wird oder nicht.
• MAX_DAYS_FOR_LOG_FILES: Wie lange wollen Sie die automatisch komprimierten log-Dateien archivieren, bevor sie gelöscht werden?
• MAX_DAYS_IN_TMP: Stellen Sie hier ein, wie lange ungenutzte Dateien in /tmp verbleiben dürfen.
• MAX_DAYS_FOR_CORE: Wie lange dürfen Corefiles Platz auf der Festplatte belegen, bevor sie gelöscht werden?
• RPMDB_BACKUP_DIR: Hier teilen Sie dem System mit, wohin die Backups der RPM-Datenbank sollen bzw., ob überhaupt Backups abgelegt werden. Mit MAX_RPMDB_BACKUP bestimmen Sie deren maximale Anzahl.
• RUN_UPDATEDB: Möchten Sie die Datenbank für locate täglich erneuern, dann tragen Sie hier yes ein.
• REINIT_MANDB: Ein yes an dieser Stelle bewirkt, dass die Manpage-Datenbank täglich auf den neuesten Stand gebracht wird.