Jak mogę ograniczyć rozmiar mojego syslog?

Mam komputer mojej mamy z systemem Ubuntu 12.04 LTS. Działa dobrze, ale nagle syslog się zapełnia. A przez wypełnienie mam na myśli, że właśnie /var/log/syslogusunąłem 400 GB. Tak - gigabajty.

Chociaż jestem pewien, że było tam kilka użytecznych informacji, nie jestem pewien, czy 400 GB to jakakolwiek informacja do przesiewania. I naprawdę niesamowite jest to, że stało się to w ciągu 8 godzin - pobiegłem dfokoło południa, a od tego czasu jej napęd zapełnił się 30% (z nieco poniżej 70% do 100%).

Co może być tego przyczyną i jak mogę to naprawić? '

EDYCJA Wygląda na to, że usb jest sprawcą:

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

Powinieneś dowiedzieć się, co powoduje dużą liczbę wiadomości, tak jakby rozwiązać ten problem, a następnie naprawić duży plik dziennika.

Jednak do tego czasu możesz ustawić podstawę rotacji dzienników na jednym z poniższych.

• czas (np. obracaj codziennie)
• rozmiar (np. obróć, gdy plik osiągnie 10 MB)

Będzie to już domyślnie ustawione w systemie: /etc/logrotate.d/rsyslog

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

Z tego widać, że będzie on codziennie obracał plik on / var / log / syslog i przechowywał 7 kopii obróconego pliku.

Możesz to zmienić, aby obrócić o limit rozmiaru, powiedzmy 1 MB lub zmniejszyć liczbę przechowywanych kopii.

Ostrzeżenie: nie usunie to głównej przyczyny problemu , jednak da ci trochę czasu, ponieważ zapełni system plików.

• Źródło: /etc/logrotate.d/rsyslog
• Źródło: man logrotate

Ogranicz rozmiar logrotatu

Otwórz /etc/logrotate.d/syslogplik konfiguracyjny

sudo nano /etc/logrotate.d/syslog

Plik wygląda na coś. lubić

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

Dodaj np. size 100k W nawiasie. Następnie powinien wyglądać następująco:

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

Zauważ, że ogranicza to rozmiar plików wirujących, a nie rzeczywisty plik syslog. Zapisz plik. Przy następnym uruchomieniu zadania Logrotate Chron ograniczy on rozmiar obróconych dzienników.

Ogranicz rozmiar bieżącego dziennika systemowego

Aby ograniczyć rozmiar /var/log/syslog, musisz edytować /etc/rsyslog.d/50-default.confi ustawić stały rozmiar dziennika.

Dodaj lub zmodyfikuj to ustawienie, zmieniając następujący wiersz w /etc/rsyslog.d/50-default.conf:

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

Oto fragment instrukcji rsyslog :

Kanały wyjściowesą zdefiniowane przez dyrektywę $ outchannel. Jego składnia jest następująca: $ nazwa outchannel, nazwa pliku, maksymalny rozmiar, nazwa działania na maksymalnym rozmiarze to nazwa kanału wyjściowego (nie pliku), nazwa pliku to nazwa pliku, w którym ma zostać zapisany , max-size maksymalny dozwolony rozmiar i action-on-max-size polecenie, które zostanie wydane po osiągnięciu maksymalnego rozmiaru. To polecenie ma zawsze dokładnie jeden parametr. Plik binarny to ta część akcji na maksymalnym rozmiarze przed pierwszą spacją, jej parametrem jest wszystko za tą spacją. Należy pamiętać, że sprawdzany jest maksymalny rozmiar PRZED zapisaniem komunikatu dziennika do pliku. Pamiętaj więc, aby ustawić ten limit na odpowiednio niskim poziomie, aby każda wiadomość mogła się zmieścić. W bieżącej wersji pomocne jest ustawienie jej o 1k niżej niż oczekiwano. Maksymalny rozmiar musi być zawsze określony w bajtach - nie ma specjalnych symboli (takich jak 1k, 1m, …) Na tym etapie rozwoju. Pamiętaj, że $ outchannel po prostu definiuje kanał z „nazwą”. Nie aktywuje go. Aby to zrobić, musisz użyć linii selektora (patrz poniżej). Ta linia wyboru zawiera nazwę kanału oraz znak $ przed nią. Przykładem może być:. : omfile: $ mychannel W obecnej formie kanały wyjściowe zapewniają przede wszystkim możliwość ograniczenia rozmiaru pliku wyjściowego. Aby to zrobić, określ maksymalny rozmiar. Po osiągnięciu tego rozmiaru rsyslogd wykona polecenie action-on-max-size, a następnie ponownie otworzy plik i spróbuje ponownie. Polecenie powinno być czymś w rodzaju skryptu rotacji dziennika lub podobną rzeczą.

Jeśli nie ma komendy action-on-max-size lub komenda nie rozwiązała sytuacji, plik jest zamykany i nigdy nie otwierany ponownie przez rsyslogd (z wyjątkiem, oczywiście, jego ukrywania). Ta logika została zintegrowana, gdy po raz pierwszy napotkaliśmy poważne problemy z plikami większymi 2 GB, co może prowadzić do rdzenia zrzutu rsyslogd. W takich przypadkach bardziej odpowiednie jest zaprzestanie zapisywania w jednym pliku. Tymczasem rsyslogd został naprawiony, aby obsługiwać pliki większe niż 2 GB, ale oczywiście tylko w systemach plików i wersjach systemów operacyjnych, które to robią. Wymuszanie ograniczenia rozmiaru pliku do 2 GB może mieć sens.

Tutaj maksymalny rozmiar to 1 MB, umieść tę linię przed *.*; ...linią

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

i zmień *.*; ...linię na

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

Uruchom ponownie rsyslogd

sudo service rsyslog restart

Miałem ten sam problem z Lexmark Pro915 przez dwa tygodnie. Zrobiłem dwie rzeczy i teraz działa dobrze. Ponownie zainstalowałem sterownik. (Nie sądzę, że to pomogło.) Wyjąłem używane przeze mnie rozszerzenie USB, które sprawiło, że całkowita długość była prawie 15 'długa i która mogła nie być w pełni kompatybilna. Podejrzewam, że sterownik Lexmarka dla systemów Linux może wykrywać słaby lub źle wyśrodkowany sygnał i chce ci o tym powiedzieć 10 miliardów razy dziennie. Spróbuj jakoś poprawić swoje połączenie.

Logrotate i podobne rozwiązania nie pomogły mi. Kern.log i syslog razem rejestrowały ponad 1 TB dziennie! Logrotate może pomóc, jeśli możesz ustawić, aby działał co 12 minut.