1260: Log-Meldungen des KernelsDer Kernel schreibt alles das, was er tut, mit. Die Log-Meldungen können an verschiedenen Stellen und in verschiedenen Detailstufen ausgegeben werden. ACHTUNG! Die in Debian Etch existierende Datei "/etc/syslog.conf" heißt in Debian Lenny nun "/etc/rsyslog.conf"! Das Ganze hat auch einen Hintergrund. Den werde ich bald hier einfließen lassen. Bis dahin nehmen Sie bitte diesen Hinweis zur Kenntnis und improvisieren entsprechend. 1. Technische GrundlagenBevor wir irgendetwas mit den Log-Meldungen des Kernels machen, beschäftigen wir uns zunächst mit den technischen Grundlagen. Die erste wichtige Erkenntnis ist die, dass es spezielle man-Pages für Kernel-Entwickler gibt. Auf eine davon verweist die man-Page von "proc". Die Eingabe von apt-cache search manpages-dev führt zu folgender Ausgabe: manpages-dev - Manual pages about using GNU/Linux for development Installieren wir also diese man-Pages, um etwas darin zu lesen: apt-get install manpages-dev Interessant ist nun der Abschnitt 2 der man-Page http://www.rt.com/man/syslog.2.html, offline nachlesbar mit diesem Befehl: man 2 syslog Eine wirklich interessante Liste in dieser man-Page bringt erste Erkenntnisse zu den Detailstufen der Log-Meldungen ans Tageslicht: #define KERN_EMERG "<0>" /* system is unusable */ #define KERN_ALERT "<1>" /* action must be taken immediately */ #define KERN_CRIT "<2>" /* critical conditions */ #define KERN_ERR "<3>" /* error conditions */ #define KERN_WARNING "<4>" /* warning conditions */ #define KERN_NOTICE "<5>" /* normal but significant condition */ #define KERN_INFO "<6>" /* informational */ #define KERN_DEBUG "<7>" /* debug-level messages */ Das heißt: Jeder Log-Meldung, die vom Kernel generiert wird, wird eine Detailstufe bzw. ein Log-Level zugewiesen. Das Log-Level betrachten wir dabei als umgekehrt proportional zur Detailstufe. Drei Beispiele:
2. Log-Meldungen in der KonsoleWenn Systemfehler auftreten (zum Beispiel: eine Festplatte ist kaputt gegangen), dann erscheinen diese Fehler auf den Konsolen (<Alt>+<F1> bis <Alt>+<F6>), damit der Benutzer sofort mitbekommt, dass etwas nicht stimmt. Aber auch Benachrichtigungen, dass ein neues USB-Gerät angesteckt wurde oder dass ein KVM-Switch Tastatur und Maus zwischen dem aktuellen und einem anderen Rechner gewechselt hat, erscheinen auf den Konsolen und zerschießen dann die Ausgaben der Software, die dort eigentlich läuft (z.B. Midnight Commander). Das kann nerven, und möglicherweise wollen Sie das ändern. Ändern können Sie die Detailstufen der Log-Meldungen in der Konfigurationsdatei "/etc/sysctl.conf". Es gibt dort den passenden Eintrag: # Uncomment the following to stop low-level messages on console #kernel.printk = 4 4 1 7 Wenn Sie also das Kommentarzeichen entfernen, und aus der ersten 4 eine 1 machen, # Uncomment the following to stop low-level messages on console kernel.printk = 1 4 1 7 dann verschwinden die Log-Meldungen, die durch An- und Abstöpseln von USB-Geräten und durch Betätigen des KVM-Switches ausgelöst werden. Aber, warum? Bevor Sie die Änderung in "/etc/sysctl.conf" abspeichern, sollten Sie zunächst einen Blick in die virtuelle Datei "/proc/sys/kernel/printk" hineinwerfen. Da drin steht: 7 4 1 7 Vor der Änderung der "/etc/sysctl.conf" war die erste der 4 Zahlen eine 7. Nach der Änderung wurde aus der 7 eine 1. Mit dem Befehl man proc können Sie herausfinden, was die Zahlen der Variable "printk" im "proc"-Baum bedeutet. Da steht:
/proc/sys/kernel/printk
The four values in this file are console_loglevel, default_mes-
sage_loglevel, minimum_console_level and default_con-
sole_loglevel. These values influence printk() behavior when
printing or logging error messages. See syslog(2) for more info
on the different loglevels. Messages with a higher priority
than console_loglevel will be printed to the console. Messages
without an explicit priority will be printed with priority
default_message_level. minimum_console_loglevel is the minimum
(highest) value to which console_loglevel can be set.
default_console_loglevel is the default value for con-
sole_loglevel.
Übersetzen wir das mal in eine verständliche Sprache. Die Variable "printk" enthält folgende 4 Werte mit den entsprechenden Bedeutungen:
Wir stellen also fest, dass für unsere Belange nur die erste Zahl interessant ist: und zwar "console_loglevel". Die zweite Zahl sollten wir so lassen, wie sie ist. Die letzten beiden Zahlen dürften nur für Kernel-Entwickler interessant sein, wenn sie sinnvolle Defaults festlegen müssen, dabei aber höhere Instanzen entscheiden lassen wollen, ob sie "console_loglevel" explizit setzen wollen oder lieber den Default-Wert nutzen wollen. Die folgende Liste zeigt, was Sie bekommen, wenn Sie "console_loglevel" auf einen Wert von 0 bis 8 setzen:
Dabei ist zu beachten, dass das Setzen von "console_loglevel" auf 0 nur theoretisch funktioniert, denn mindestens ist "minimum_console_level" in der Regel auf 1 gesetzt. Auch ein Setzen von "console_loglevel" auf 8 produziert nicht unbedingt auf Anhieb Debug-Meldungen, was wohl daran liegen kann, dass an anderer Stelle das Generieren von Debug-Meldungen unterdrückt wurde, um die System-Performance nicht unnötig zu belasten. Wenn Sie wollen, dass Meldungen vom KVM-Switch nicht mehr die Konsole verunstalten, dann müssen Sie je nach Rechner "console_loglevel" entweder auf 6 oder auf 4 setzen. Der KVM-Switch verursacht Meldungen vom Typ KERN_INFO (Log-Level 6). Wenn ein Rechner eine gewisse "compaq touchscreen emulation" nicht verträgt (was auch immer das für ein Quatsch sein mag), dann verursacht der KVM-Switch zusätzlich noch Meldungen vom Typ KERN_WARNING (Log-Level 4). Sie sind daher auf der sicheren Seite, wenn Sie alle Log-Meldungen ab Log-Level 4 ausblenden und "console_loglevel" entsprechend auf 4 setzen. Wenn Sie wollen, dass auch Meldungen von USB-Massenspeichern die Konsole nicht verunstalten, dann müssen Sie "console_loglevel" sogar noch niedriger setzen, zum Beispiel auf 3, um unsinnig priorisierte Fehlermeldungen der Sorte "sdb: assuming drive cache: write through" auszublenden. Meine Empfehlung ist, "console_loglevel" auf 1 zu setzen, damit auf der Konsole Ruhe ist. Nur noch Log-Meldungen vom Typ EMERGENCY können dann noch die Konsole verunstalten. Auf einem System, das unbenutzbar ist, ist das aber nicht so tragisch. Übrigens: Sie können die Werte der Variablen auch in "/proc/sys/kernel/printk" direkt ändern: echo '1 4 1 7' > /proc/sys/kernel/printk Die Änderungen sind aber nicht persistent (von Dauer). Beim nächsten Reboot wird dort wieder der Wert von "/etc/sysctl.conf" stehen. 3. Log-Meldungen auf Konsole 10 und 11Es kann ganz praktisch sein, die Log-Meldungen auf eine Konsole zu leiten, die extra für Log-Meldungen eingerichtet wurde. Dazu nutzen wir jetzt die Datei "/etc/syslog.conf". Verantwortlich für die Ausgabe der Log-Meldungen an verschiedene Ziele ist der Daemon "syslogd". Nachlesen können Sie dessen Konfiguration mit einem der beiden Befehle: man syslog.conf man 5 syslog.conf Die Datei "/etc/syslog.conf" enthält mehrere sogenannte "Rules". Eine Rule ist eine Konfigurationsangabe, die vereinfacht gesagt angibt, was wohin geschrieben werden soll. 3.1. Aufbau einer Rule
Eine Rule besteht aus zwei Feldern, also aus einem Selector und einer Action, die durch Leerzeichen oder Tabs voneinander getrennt sind, und sieht entsprechend so aus: selector action 3.2. Aufbau eines Selectors
Ein Selector besteht wiederum aus einer Facility, gefolgt von einem Punkt, gefolgt von einer Priority. Entsprechend sieht eine Rule so aus: facility.priority action 3.3. Was bedeuten die einzelnen Komponenten?
Die folgende Liste zeigt, was die einzelnen Komponenten bedeuten:
3.4. Kombination und Verteilung
Mehrere Facilities können per Komma getrennt aufgelistet werden: facility1,facility2,facility3.priority action Mehrere Selectors können per Semikolon getrennt aufgelistet werden: facility1a,facility1b.priority1;facility2a,facility2b.priority2 action Eine Rule kann auf mehrere Zeilen verteilt werden, wenn zwischen zwei Selectors statt eines Semikolons nacheinander ein Semikolon, ein Backslash, ein Zeilenumbruch und Leerzeichen oder Tabs stehen. Dabei ist zu beachten, dass ohne Verwendung von Backslashs keine Leerzeichen zwischen den Selectors stehen dürfen, vor den Backslashs keine Leerzeichen stehen dürfen und die Backslash-Konstruktion nur zwischen Selectors, aber nirgendwo sonst funktioniert. Ein Beispiel: facility1a,facility1b.priority1;\ facility2a,facility2b.priority2; action So nicht: facility1a,facility1b.priority1; \ facility2a,facility2b.priority2; \ action Beachten Sie bitte, dass Priorities NICHT per Komma getrennt aufgelistet werden können. Eine solche Rule ist falsch und wird daher ignoriert: facility.priority1,priority2,priority3 action 3.5. Mögliche Angaben für Facility Unter anderem sind folgende Schlüsselwörter für die Facility möglich: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7 Was diese Facilities bedeuten, das können Sie hier nachlesen: man syslog Ein Stern ("*") steht für alle Facilities. 3.5. Mögliche Angaben für Priority
Unter anderem sind folgende Schlüsselwörter für die Priority möglich: emerg, alert, crit, err, warning, notice, info, debug Eine "Kernel-Panic", wie sie früher existierte, wäre heute ein "Kernel-Emergency", da das Schlüsselwort "emerg" das Schlüsselwort "panic" abgelöst hat. Ein Stern ("*") steht für alle Priorities. Wenn eine Priority angegeben wurde, dann sind damit alle Log-Meldungen gemeint mit dieser Detailstufe und allen niedrigeren. Beispiel: Ein "err" steht für "emerg", "alert", "crit" und "err". Wenn vor die Priority ein "=" gesetzt wird, dann ist damit explizit die angegebene Detailstufe gemeint. Beispiel: Ein "=err" steht für ein "err", für nicht mehr und nicht weniger. Ein "!" negiert das, was nach ihm folgt. Beispiel: Ein "!=err" steht für alles außer ein "err". Ein "!err" steht für "warning", "notice", "info" und "debug". Ein "!*" oder ein "none" veranlasst, dass gar keine Log-Meldungen verarbeitet werden. 3.6. Mögliche Angaben für Action
Als Angaben für die Action kommen folgende Möglichkeiten in Frage:
Wenn die Action eine Datei ist und vor dem Dateinamen ein Minus ("-") steht, dann heißt das, dass nach dem Schreiben der Log-Meldung in die Datei der Cache dieser Datei nicht sofort auf die Festplatte geschrieben wird, um Performance zu sparen (die Informationen verbleiben physikalisch im RAM und der logische Dateiinhalt wird dann auf die Festplatte geschrieben, wenn das System sowieso gerade Leerlaufzeiten hat). Es besteht das Risiko, dass neue Log-Meldungen verloren gehen, wenn das System zeitlich zwischen dem logischen und dem physikalischen Schreiben abstürzt. 3.7. Beispiel-Rules
Nachdem wir in die Materie eingetaucht sind, konstruieren wir aus den Komponenten nun die ersten Rules, um das alles besser zu verstehen. Die folgende Rule sendet alle Kernel-Log-Meldungen in die Datei "/var/log/messages-test1" unter Verwendung eines Schreib-Caches: kern.* -/var/log/messages-test1 Diese Rule sendet alle Kernel-Log-Meldungen mit einem Log-Level ab "crit" in die Datei "/var/log/messages-test2" ohne Schreib-Cache, also sofort und damit einigermaßen geschützt vor Datenverlust: kern.crit /var/log/messages-test2 Diese Rule sendet alle Log-Meldungen, die es gibt in die Datei "/var/log/messages-test3" unter Verwendung eines Schreib-Caches: *.* -/var/log/messages-test3 Diese Rule sendet Log-Meldungen mit den Priorities "err" und "warning" von allen Facilities, mit Ausnahme des Kernels, in die Datei "/var/log/messages-test4" unter Verwendung eines Schreib-Caches: *.err;*.warning;kern.none -/var/log/messages-test4 Das Gleiche noch einmal, nur über mehrere Zeilen verteilt: *.err;\ *.warning;\ kern.none -/var/log/messages-test5 3.8. Lösungsansatz
Sie wissen jetzt alles, was Sie benötigen, um die Log-Ausgaben zu konstruieren, die Sie sehen möchten. Um die Log-Ausgaben auf die Funktionstaste F10 zu legen, können Sie in der Datei "/etc/syslog.conf" den folgenden vorhandenen Absatz auskommentieren und abändern: # # I like to have messages displayed on the console, but only on a virtual # console I usually leave idle. # #daemon,mail.*;\ # news.=crit;news.=err;news.=notice;\ # *.=debug;*.=info;\ # *.=notice;*.=warn /dev/tty8 Das empfehle ich aber nicht, weil eine solche Rule sicherlich sinnvoller aufgeschrieben werden kann, ohne Ballast aus dem letzten Jahrhundert. Folgende Rules empfehle ich: # eigene Rules 01 *.* /dev/tty10 *.err /dev/tty11 kern.err /dev/tty12 Mit diesen Rules bekommen Sie alle existierenden Log-Meldungen auf die Konsole 10, alle Log-Meldungen mit einer Detailstufe kleiner/gleich 3 auf die Konsole 11 und alle Kernel-Log-Meldungen mit einer Detailstufe kleiner/gleich 3 auf die Konsole 12. 3.9. Hinweis
Wenn Sie die Ausgabe der Log-Meldungen in die aktuelle Konsole (per "/etc/sysctl.conf") nicht unterdrückt haben, dann müssen Sie beim Betrachten der Konsolen 10 bis 12 damit rechnen, dass während der Betrachtung Meldungen doppelt in der gerade offenen Konsole erscheinen! Einmal erscheint sie, weil sie in die aktuelle Konsole ausgegeben wurde und ein weiteres mal, weil sie in die Konsole ausgegeben wurde, die Sie zufällig gerade betrachten. 4. Log-FilesZusätzlich zu "/var/log/messages", "/var/log/debug" und den anderen Log-Files, können Sie sich noch eigene Log-Files anlegen: # eigene Rules 02 *.crit /var/log/meldungen 5. Web-Links
|