 |
|
|||||
|
Umgang mit großen Protokolldateien
Häufig ist es erforderlich, Protokolldateien ständig zu beobachten.
Der Befehl
gaston# cd /var/log gaston# tail -f messages Jun 18 20:11:36 gaston pppd[2592]: sent [LCP TermReq id=0x4 "Us er request"] Jun 18 20:11:36 gaston pppd[2592]: rcvd [LCP TermAck id=0x4] Jun 18 20:11:36 gaston pppd[2592]: Connection terminated. Jun 18 20:11:36 gaston pppd[2592]: Connect time 0.4 minutes. Jun 18 20:11:36 gaston pppd[2592]: Sent 3333 bytes, received 25 062 bytes. Jun 18 20:11:36 gaston pppd[2592]: Waiting for 1 child processe s... Jun 18 20:11:36 gaston pppd[2592]: script /etc/ppp/ip-down, p id 2616 Jun 18 20:11:36 gaston pppd[2592]: Script /etc/ppp/ip-down fini shed (pid 2616), status = 0x0 Jun 18 20:11:36 gaston pppd[2592]: Exit. Jun 18 20:26:54 gaston su: (to root) arnold on /dev/pts/6
Wenn eine Protokolldatei lange Zeit nur gefüllt wurde, kann sie leicht einige
Megabyte groß werden. Dann wird es schwierig, sie zu handhaben,
um nach bestimmten Stichwörtern oder Tagen zu suchen. Typischerweise ist man an
den
etwas neueren Informationen interessiert. Mit
tail -2000 messages > guckmal Damit sind die letzten 2000 Zeilen in der Datei guckmal gelandet. Mit dieser Dateigröße lässt sich leicht arbeiten. Es ist eine ganz schlechte Idee, eine Protokolldatei einfach zu löschen, wenn man der Meinung ist, dass sie zu voll geworden ist. Normalerweise ist diese Datei von dem Erzeuger des Protokolls geöffnet worden. Verschwindet die Datei, schreibt der Prozess ins Nirwana. Kaum ein Programm reagiert auf Fehler beim Schreiben, indem es die Datei neu anlegt. Um die Datei /var/log/messages auf 0 zurückzusetzen, geben Sie den folgenen Befehl ein:
> /var/log/messages
Diese etwas brutale Methode kann man auf seiner eigenen Workstation durchaus
praktizieren. Auf einer Produktionsmaschine wird man Protokolle normalerweise
eine Zeit lang archivieren.
Die spontane Idee ist, die Datei messages zu kopieren und sie dann wie
oben gesehen zu stutzen. Das Problem ist, dass dabei ein Zeitloch entsteht, in
dem Fehlermeldungen verschwinden. Eine Fehlermeldung, die nach dem Erstellen
der Kopie und vor dem Stutzen der messages entsteht, würde verloren
gehen. Darum geht man so vor, dass man zunächst die Datei
umbenennt. Der Dateizugriff wird dadurch nicht gestört, da die Prozesse beim
Bearbeiten von Dateien nur einmal beim Öffnen auf den Dateinamen verweisen.
Danach wird nur noch über eine Kennung auf die Datei zugegriffen. Was
währenddessen in den Verzeichniseinträgen passiert, ist dem Prozess
ziemlich egal.
Nun legt man eine neue Protokolldatei mit
gaston# cd /var/log gaston# fuser messages messages: 378
Prozess 378 greift auf die Datei messages zu.
Vermutlich ist das der
gaston# mv messages messages.$(date +%y%m%d) gaston# fuser messages. $(date +\%y\%m\%d) messages.020224: 378$ Die Datei wurde nun umbenannt. Immer noch greift der Prozess mit der PID 378 auf sie zu, obwohl der Name der Datei sich geändert hat.
gaston# touch messages gaston:/var/log # l messages* -rw-r-r- 1 root root 0 Feb 24 12:07 messages -rw-r--- 1 root root 2447648 Feb 24 12:06 messages.020224 gaston# chmod 640 messages gaston# l messages* -rw-r--- 1 root root 0 Feb 24 12:07 messages -rw-r--- 1 root root 2447648 Feb 24 12:06 messages.020224 Die neue Protokolldatei wurde erfolgreich angelegt und mit den Rechten der alten versehen. Auch der Eigentümer stimmt überein.
gaston# ps -ef | grep syslog root 378 1 0 10:24 ? 00:00:00 /sbin/syslogd root 1486 1465 0 12:09 pts/2 00:00:00 grep syslog gaston# kill -SIGHUP 378
Sicherheitshalber wird noch einmal geprüft, ob der Prozess 378 tatsächlich
der syslogd ist. PID 1486 ist der eigene Prozess, der die Prozessliste
durchsucht. Nun wird mit dem Befehl
gaston# fuser messages messages: 378 gaston# gzip messages.$(date +%y%m%d) Erwartungsgemäß hat der syslogd die Datei messages und damit die gerade neu untergeschobene eröffnet. Die alte Protokolldatei kann gepackt werden.
Mit Hilfe des Befehls Da solche Arbeiten auf Produktionsmaschinen regelmäßig auftreten, ist es ein nahe liegender Gedanke, sie in die crontab (siehe S. crontab) zu integrieren.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
bestellen
