4.1 Fehler / Logging. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 1 von 29

Transkript

1 Bei allen Systemaufrufen unter UNIX können Fehlersituationen auftreten. Diese werden durch den universellen Funktionswert -1 der aufgerufenen C-Funktion angezeigt, in manchen Fällen auch durch einen Null-Pointer (NULL) als Resultat. Es ist die Pflicht des Systemprogrammierers, einen Test auf den jeweiligen Fehlerwert durchzuführen. Die eben genannte Konvention ist wegen ihrer Einfachheit nützlich, gibt aber noch nicht den Grund für den aufgetretenen Fehler an. In fast allen Fällen ist es jedoch sinnvoll, daß das den System-Call ausführende Programm Aufschluß über die Fehlerursache bekommt und damit eventuell geeignet darauf reagieren kann. Fehlercodes Jeder bei Systemaufrufen vorkommende Fehler hat deshalb eine Nummer, einen mnemonischen Code zur Nummer, und normalerweise einen String mit einer Meldung. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 1 von 29

2 Man kann dies alles benutzen durch Einfügen von #include <errno.h> ins Programm. Dies bewirkt bei korrekten Include-Files auch, daß die Variablen extern int errno; extern char *sys_errlist[]; extern int sys_nerr; bekannt sind. Die Fehlervariable errno wird vom Systemaufruf gesetzt, wenn ein Fehler auftritt. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 2 von 29

3 #include <stdio.h> /* wegen fprintf, stderr */ #include <sys/types.h> /* u. U. wegen fcntl.h */ #include <fcntl.h> /* damit O_RDONLY definiert ist */ #include <errno.h> #define FEHLER -1 char filename[] = "nichtda"; main() { if (open(filename, O_WRONLY) == FEHLER) if (errno == ENOENT) fprintf(stderr, "File %s nicht vorhanden\n", filename); else if (errno == EACCES) fprintf(stderr, "Schreibzugriff auf %s nicht H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 3 von 29

4 erlaubt\n", filename); } else fprintf(stderr, "Fehler Nr %d\n", errno); return 0; H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 4 von 29

5 Im Include-File <errno.h> sind die manifesten Konstanten (wie z.b. ENOENT) definiert, die errno annehmen kann. Die möglichen Werte hängen naturgemäß sehr vom System ab. In Anhang C des Buchs sind alle Fehlercodes unter UNIX aufgeführt. Noch einfacher und komfortabler arbeitet man mit der UNIX-Subroutine (kein System-Call!) perror: Die perror-subroutine void perror(char *message); Diese Funktion gibt auf der Standardfehlerdatei einen Text aus, der aus dem übergebenen String, einem Doppelpunkt und einer zusätzlichen, mit dem Wert von errno zusammenhängenden Meldung besteht, die in sys_errlist[errno] H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 5 von 29

6 gespeichert ist. Es folgt ein Zeilenvorschub. Ersetzt man in obigem Beispiel die gesamte if (errno == FEHLER)...-Anweisung durch if (errno == FEHLER) perror("fehler beim Öffnen"); so erscheint z.b. die Meldung Fehler beim Öffnen: No such file or directory. Die externe Variable sys_nerr schließlich enthält die Gesamtzahl der in sys_errlist vorhandenen Meldungen. Mit folgendem Programm können Sie alle Fehlermeldungen ihres Systems ausdrucken: H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 6 von 29

7 #include <stdio.h> extern sys_nerr; extern char *sys_errlist[]; main() { int count; char *s; } for (count = 0; count < sys_nerr; count++) if ((s = sys_errlist[count])!= NULL) printf("%3d : %s\n", count, s); H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 7 von 29

8 Logging Auf einem System laufen, selbst wenn man momentan gerade nicht direkt damit arbeitet, stets viele Dienste. Bei typischen Linux-Installationen sind es schnell einhundert Prozesse, die im Hintergrund ihre Arbeit verrichten. Auf einem Server ist "ständig was los", auch wenn man diesem das nicht unbedingt ansieht. Etliche dieser Hintergrundprozesse sind Dienste, Server oder Daemons. Alle drei Begriffe bedeuten im Wesentlichen das Gleiche. Beispiele für solche Dienste sind FTP-, Web- und Mailserver. Da ein Dienst über keine direkte Benutzerschnittstelle verfügt (das heißt, er hat kein Kontroll-Terminal oder "Fenster"), kann er Meldungen und Fehler nicht direkt an den Benutzer melden. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 8 von 29

9 Oft sind die Benutzer, die gerade mit einem System arbeiten, auch nicht die gewünschten Empfänger, denn viele Meldungen sind für Systemadministratoren gedacht. Auf kleinen Systemen jedoch sind die Benutzer oft gleichzeitig Administratoren. Um einen ordnungsgemäßen Betrieb zu gewährleisten, muß das System überwacht, und gegebenenfalls auf Fehler reagiert werden. Auch der Linux-Kernel selbst erzeugt Meldungen, beispielsweise über Hardwarefehler (wie defekte Festplatten). H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 9 von 29

10 Logdateien Um derartige Meldungen zu verarbeiten, können diese beispielsweise in Logdateien geschrieben werden. Diese können dann von Zeit zu Zeit von einem Administrator geprüft werden, oder bei Fehleranalysen verwendet werden. Der Apache-Webserver schreibt beispielsweise solche Logdateien. Dieser Weg ist aber für Meldungen von vielen kleineren Diensten umständlich, da man viele Logdateien in unterschiedlichen Formaten analysieren müßte: zwanzig verschiedene Dienste würden zwanzig verschiedene Logdateien schreiben. Ein Dienst, der dafür zuständig ist, von beliebigen Diensten Meldungen einzusammeln, und zentral in Logdateien zu schreiben, ist Syslog. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 10 von 29

11 Syslog - der System Logger Syslog bietet anderen Diensten eine Schnittstelle, über die Meldungen übergeben werden. Syslog verarbeitet diese Meldungen dann weiter, in dem sie in Dateien geschrieben werden. Dieser Dienst ist einfach zu handhaben und wird deshalb insbesondere von kleineren Diensten gerne verwendet. Diese Dienste müssen sich dann nicht alle einzeln um Logdateien kümmern. Für den Administrator hat dies Vorteile: Es gibt eine zentrale Konfigurationsdatei und zentrale Logdateien. Zusätzlich erlaubt es Syslog auch, Logmeldungen an andere Server über das Netzwerk weiterzureichen. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 11 von 29

12 Auf dem Zielserver nimmt wiederum Syslog diese Nachrichten ab, und schreibt sie in Logdateien. Damit lassen sich die Nachrichten von mehreren Systemen auf einem Server zusammenfassen. Meldungen Wenn ein Dienst den Syslog-Dienst verwendet, schickt er seine Meldungen also einfach an Syslog. Eine Meldung ist im Wesentlichen eine Textzeile. Zusätzlich enthält diese noch einige Statusinformationen, beispielsweise wie wichtig diese Meldung ist und zu welchem "Themengebiet" sie gehört bzw. von welcher Quelle sie kommt. Syslog prüft anhand dieser Werte, ob und wie diese Meldung verarbeitet werden soll. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 12 von 29

13 Man kann Syslog zum Beispiel so konfigurieren, dass wichtige Meldungen in der einen und unwichtige in einer anderen Datei stehen, oder dass alle Meldungen, die vom Mailsystem kommen, auf einen anderen Rechner übertragen werden sollen, und weiteres. Facilities Syslog definiert eine Reihe von Quellen oder Themengebieten für Meldungen. Diese werden als facilities bezeichnet. Dabei ist es nur eine Konvention, wann welche Facility verwendet wird. Manchmal ist eine eindeutige Zuordnung nicht einfach möglich. Hier muß man nachsehen, welche Facility ein Dienst benutzt (bei manchen Diensten läßt sich diese auch einstellen). H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 13 von 29

14 Übersicht über Facilities auth, authpriv cron daemon kern Meldungen, die zur Authentifizierung gehören, beispielsweise falsche Passwörter Meldungen, die von Cron erzeugt wurden, oder von Prozessen, die von Cron gestartet werden (die Standard-Ausgabe und Stardard-Fehler-Ausgabe werden jedoch von Cron nicht an Syslog gereicht, sondern per verschickt) Meldungen von allgemeinen Diensten, wie zum Beispiel einem FTP-Server Meldungen des Systemkernels. Sollte von keinem Dienst verwendet werden. Hierzu gehören beispielsweise Hardware-bezogene Meldungen H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 14 von 29

15 lpr Meldungen des Drucksystems (Druckerspooler) mail Meldungen des Mailsystems (beispielsweise von sendmail und fetchmail) mark Nur für Syslog-interne Zwecke, sollte nie verwendet werden news Meldungen des News-Systems, zum Beispiel eines Newsservers syslog Meldungen von Syslog selbst user Meldungen von Benutzersystemen wie zum Beispiel eigenen Scripten uucp Meldungen von Unix-Unix-Copy (UUCP wird heute kaum noch verwendet) local0,, local7 Diese sind frei und können nach Belieben verwendet werden. Bei Diensten, bei denen man die zu verwendende Facility einstellen kann, kann man diese verwenden und je nach Bedarf verteilen H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 15 von 29

16 Priorität von Meldungen Syslog definiert eine Reihe von Namen, die die Wichtigkeit beschreiben. Diese Priorität wird englisch als priority oder severity bezeichnet. Manchmal spricht man auch vom log level. Auch diese Eigenschaft kann man verwenden, um die Meldungen differenziert zu verarbeiten, wie bereits angedeutet. Übersicht über Prioritäten: debug Unwichtige Meldungen, dienen nur zu Debug-Zwecken (Fehlersuche vor allem bei der Entwicklung) info Informative, nicht weiter wichtige Meldungen notice Informative Meldungen, die größere Bedeutung haben als info H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 16 von 29

17 warning Warnungen, also Meldungen, die nicht-fatale Fehler anzeigen err Fehlermeldungen, die kleine Störungen anzeigen crit Kritische (schwerere) Fehler, die beispielsweise Teilausfälle anzeigen alert Schwere Fehler, die erhebliche Störungen und Ausfälle anzeigen. emerg Sehr schwere Fehler, die beispielweise den Totalausfall des Systems anzeigen können und schwere Kernelfehler (Hardwareausfälle) Faustregel: Alles, was wichtiger oder gleich warning ist, verdient auf jeden Fall Aufmerksamkeit H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 17 von 29

18 Weitere Eigenschaften von Meldungen Zu diesen beiden essentiellen Eigenschaften kommen hinzu: Zeitpunkt der Meldung (diese wird von Syslog automatisch beigefügt) Prozeß-ID des Prozesses, der die Meldung erzeugte ein Tag, das meistens den Namen des Programmes enthält, das die Meldung erzeugte Hostname des Systems (wichtig bei Netzwerk-Logging) H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 18 von 29

19 Format der Meldungen Eine Meldung ist immer eine Zeile mit 1. Zeitstempel 2. Hostname des Systems 3. Tag (also meistens der Programmname) und in eckigen Klammern dessen Prozeß-ID 4. Rest der Zeile ist die Textnachricht dieser Meldung Bei einigen Meldungen weicht das Format geringfügig ab, beispielsweise kann die Prozeß-ID entfallen (wie etwa bei Kernel und syslog-meldungen) Die Facility und Priority sind aus einer solchen Zeile leider nicht mehr erkennbar H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 19 von 29

20 Beispiel für eine Logmeldung: /var/log/messages Mar 10 13:30:30 atlas syslogd 1.3-3: restart. Diese Meldung wurde am 10. März um 13:30 Uhr auf einem Host namens atlas erzeugt, und gibt an, dass Syslog gestartet wurde (diese Meldung erzeugt Syslog selbst beim Start). Logmeldungen selbst erzeugen 1. UNIX-Kommando: logger 2. Programmierung H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 20 von 29

21 Programmierung openlog Syslog öffnen syslog Syslog-Meldung schreiben closelog Syslog schliessen H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 21 von 29

22 Die openlog Subroutine (POSIX) #include <syslog.h> void openlog(const char* ident, int option, int facility); Es wird eine Verbindung zu Syslog hergestellt. Ident: normalerweise der Programmname H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 22 von 29

23 Werte für option sind: LOG_CONS - Write directly to system console if there is an error while sending to system logger LOG_NDELAY - Open the connection immediately (normally, the connection is opened when the first message is logged) LOG_NOWAIT - Don t wait for child processes that may have been created while logging the message LOG_ODELAY - The converse of LOG_NDELAY; opening of the connection is delayed until syslog() is called (default) LOG_PERROR - (Not in POSIX ) Print to stderr as well LOG_PID - Include PID with each message H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 23 von 29

24 Werte für facility sind: LOG_AUTHPRIV LOG_CRON LOG_DAEMON LOG_FTP LOG_KERN LOG_LOCAL0 - LOG_LOCAL7 LOG_LPR LOG_MAIL LOG_NEWS LOG_SYSLOG LOG_USER (default) LOG_UUCP H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 24 von 29

25 Die syslog Subroutine (POSIX) #include <syslog.h> void syslog(int priority, const char *format,...); Es wird eine Log-Meldung generiert, die von syslogd verteilt wird. Das Argument priority word mit OR aus facility (s.o.) und level (s.u.) gebildet. Das Argument format funktioniert ähnlich wie in printf, die restlichen Argumente müssen dazu passen. H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 25 von 29

26 Werte für level sind: LOG_EMERG LOG_ALERT LOG_CRIT LOG_ERR LOG_WARNING LOG_NOTICE LOG_INFO LOG_DEBUG Beispiel für Aufruf: syslog(log_alert LOG_USER, "%s %d", "Mist", nr); H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 26 von 29

27 Die closelog Subroutine (POSIX) #include <syslog.h> void closelog(void); Schliesst die Verbindung zu Syslog (optional). H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 27 von 29

28 Auszug aus /var/log/messages als Beispiel Nov 7 15:26:48 wap03 sshd[13070]: Did not receive identification string from Nov 7 15:36:52 wap03 zmd: NetworkManagerModule (WARN): Failed to connect to NetworkManager Nov 7 15:37:16 wap03 zmd: Daemon (WARN): Not starting remote web server Nov 7 16:16:36 wap03 syslog-ng[2348]: STATS: dropped 0 Nov 7 16:36:52 wap03 zmd: ShutdownManager (WARN): Preparing to sleep... Nov 7 16:36:52 wap03 zmd: ShutdownManager (WARN): Going to sleep, waking up at 11/08/ :26:52 Nov 7 17:16:36 wap03 syslog-ng[2348]: STATS: dropped 0 Nov 7 18:16:37 wap03 syslog-ng[2348]: STATS: dropped 0 Nov 7 19:06:09 wap03 sshd[13569]: Accepted publickey for hweber from port ssh2 Nov 7 19:07:05 wap03 su: (to root) hweber on /dev/pts/6 H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 28 von 29

29 4.1 - Fehler / Logging H. Weber, HS RM SS 2010 Systemprogrammierung Kap. 4.1 Seite 29 von 29