Wie beschränke ich die Größe meines Syslogs?

Auf dem Computer meiner Mutter läuft Ubuntu 12.04 LTS. Es hat einwandfrei funktioniert, aber plötzlich füllt sich der Syslog. Und mit dem Auffüllen meine ich, /var/log/syslogdass ich gerade eine 400 GB große gelöscht habe . Ja, Gigabyte.

Ich bin mir zwar sicher, dass einige nützliche Informationen enthalten waren, aber ich bin mir nicht sicher, ob 400 GB Informationen sind, die durchsucht werden müssen. Und das wirklich Erstaunliche daran ist, dass es innerhalb von 8 Stunden passiert ist - ich war dfgegen Mittag gelaufen und zwischen damals und heute war ihr Laufwerk zu 30% voll (von knapp 70% auf 100%).

Was könnte das verursachen und wie könnte ich das beheben? `

BEARBEITEN Sieht aus wie der USB der Täter ist:

Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157829] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157836] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157842] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157849] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157857] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157863] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157870] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157877] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157884] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use
Sep  8 08:52:10 pamela-desktop kernel: [ 6198.157891] usb 1-3: usbfs: process 1500 (demond_nscan) did not claim interface 3 before use

Sie sollten herausfinden, was die große Menge an Nachrichten verursacht. Wenn Sie dieses Problem beheben, beheben Sie die große Protokolldatei.

Bis dahin können Sie jedoch eine Protokollrotationsbasis auf eine der folgenden Arten einfügen.

• Zeit (zB jeden Tag drehen)
• Größe (zB drehen, wenn die Datei 10 MB erreicht)

Dies wird bereits standardmäßig auf dem System eingerichtet: /etc/logrotate.d/rsyslog

 /var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
            reload rsyslog >/dev/null 2>&1 || true
    endscript
 }

Daraus können Sie ersehen, dass die Datei / var / log / syslog täglich gedreht wird und 7 Kopien der gedrehten Datei aufbewahrt werden.

Sie können dies ändern, um eine Größenbeschränkung festzulegen, beispielsweise 1 MB, oder die Anzahl der darin gespeicherten Kopien zu verringern.

Warnung: Dies behebt nicht die Hauptursache Ihres Problems , verschafft Ihnen jedoch Zeit, da das Dateisystem nicht mehr voll ist.

• Quelle: /etc/logrotate.d/rsyslog
• Quelle: Mann logrotieren

Begrenzen Sie die Größe der Logrotate

Öffnen Sie die /etc/logrotate.d/syslogKonfigurationsdatei

sudo nano /etc/logrotate.d/syslog

Die Datei sieht aus wie etw. mögen

/var/log/syslog
{
    rotate 7
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}
....
...

Ergänzen Sie zB size 100k in der Klammer. Danach sollte es so aussehen:

/var/log/syslog
{
    rotate 7
    size 100k
    daily
    missingok
    notifempty
    delaycompress
    compress
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate
    endscript
}

Beachten Sie, dass dies die Dateigröße der rotierenden Dateien und nicht die tatsächliche Syslog-Datei begrenzt. Speicher die Datei. Beim nächsten Start des Logrotate-Chron-Jobs wird die Größe der gedrehten Protokolle begrenzt.

Begrenzen Sie die Größe des aktuellen Syslogs

Um die Größe von zu begrenzen /var/log/syslog, müssen Sie die bearbeiten /etc/rsyslog.d/50-default.confund eine feste Protokollgröße festlegen.

Fügen Sie diese Einstellung hinzu oder ändern Sie sie, indem Sie die folgende Zeile in ändern /etc/rsyslog.d/50-default.conf:

.*;auth,authpriv.none       -/var/log/syslog

Hier ein Auszug aus dem rsyslog-Handbuch :

Ausgangskanälewerden über eine $ outchannel-Direktive definiert. Die Syntax lautet wie folgt: $ outchannel name, file-name, max-size, action-on-max-size name ist der Name des Ausgabekanals (nicht der Datei), file-name ist der Dateiname, in den geschrieben werden soll , max-size die maximal zulässige Größe und Aktion bei maximaler Größe, die ein Befehl ausgibt, wenn die maximale Größe erreicht ist. Dieser Befehl hat immer genau einen Parameter. Die Binärdatei ist der Teil von action-on-max-size vor dem ersten Leerzeichen. Ihr Parameter ist alles hinter diesem Leerzeichen. Bitte beachten Sie, dass die maximale Größe abgefragt wird, BEVOR die Protokollmeldung in die Datei geschrieben wird. Stellen Sie daher sicher, dass dieses Limit angemessen niedrig eingestellt ist, damit jede Nachricht passt. In der aktuellen Version ist es hilfreich, 1 KB niedriger als erwartet einzustellen. Die maximale Größe muss immer in Bytes angegeben werden - es gibt keine speziellen Symbole (wie 1k, 1m, …) Zu diesem Zeitpunkt der Entwicklung. Denken Sie daran, dass $ outchannel nur einen Kanal mit "Name" definiert. Es aktiviert es nicht. Dazu müssen Sie eine Auswahllinie verwenden (siehe unten). Diese Auswahlzeile enthält den Kanalnamen sowie ein $ -Zeichen davor. Ein Beispiel könnte sein:. : omfile: $ mychannel In der aktuellen Form bieten Ausgabekanäle in erster Linie die Möglichkeit, eine Ausgabedatei in der Größe zu begrenzen. Geben Sie dazu eine maximale Größe an. Wenn diese Größe erreicht ist, führt rsyslogd den Befehl action-on-max-size aus, öffnet die Datei erneut und versucht es erneut. Der Befehl sollte so etwas wie ein Protokollrotationsskript oder ähnliches sein.

Wenn es keinen Befehl für die maximale Größe gibt oder der Befehl die Situation nicht behebt, wird die Datei geschlossen und von rsyslogd nie wieder geöffnet (außer natürlich durch Hupen). Diese Logik wurde integriert, als wir zum ersten Mal schwerwiegende Probleme mit Dateien mit einer Größe von 2 GB hatten, die zu einem Speicherauszug von rsyslogd führen konnten. In solchen Fällen ist es besser, das Schreiben in eine einzelne Datei zu beenden. In der Zwischenzeit wurde rsyslogd so repariert, dass es Dateien mit mehr als 2 GB unterstützt, jedoch offensichtlich nur auf Dateisystemen und Betriebssystemversionen, die dies tun. Es kann also trotzdem sinnvoll sein, eine Dateigrößenbeschränkung von 2 GB durchzusetzen.

Hier beträgt die maximale Größe 1 MB. Platzieren Sie diese Zeile vor der *.*; ...Zeile

$outchannel mysyslog,/var/log/syslog,1048576

und ändern Sie die *.*; ...Zeile in

*.*;auth,authpriv.none  :omfile:$mysyslog

Starten Sie rsyslogd neu

sudo service rsyslog restart

Ich hatte zwei Wochen lang das gleiche Problem mit einem Lexmark Pro915. Ich habe zwei Dinge getan, und es funktioniert jetzt gut. Ich habe den Treiber neu installiert. (Ich glaube nicht, dass dies geholfen hat.) Ich habe die USB-Erweiterung, die ich verwendet habe, entfernt, wodurch die Gesamtlänge fast 15 Fuß betrug und die möglicherweise nicht vollständig kompatibel war. Ich vermute, dass der Lexmark-Treiber für Linux-Systeme möglicherweise ein schlechtes oder zeitgesteuertes Signal erkennt und Ihnen 10 Milliarden Mal am Tag davon berichten möchte. Versuchen Sie, Ihre Verbindung irgendwie zu verbessern.

Logrotate und ähnliche Lösungen haben mir nicht geholfen. Kern.log und syslog haben zusammen mehr als 1 TB pro Tag protokolliert! Logrotate könnte helfen, wenn Sie festlegen könnten, dass es alle zwölf Minuten ausgeführt wird.