log verzeichniss mehrere gigabyte groß???

steven · Beitrag von **steven** » 21.02.2005 15:12:57

hallo leute.
mein debian unstable hat irgendwie probleme mit der größe von logdateien. meine syslog debug und kern.log wachsen innerhalb von ner woche immer auf eine größe von 1 gigabyte an. woran liegt das?
bis jetzt hab ich sie einfach manuell gelöscht. gibt es nicht eine möglichkeit das löschen von einem deamon machen zu lassen?

lochkarte · Beitrag von **lochkarte** » 21.02.2005 15:14:50

Code: Alles auswählen

apt-get install logrotate anacron

steven · Beitrag von **steven** » 21.02.2005 16:30:59

hab das jetzt einfach installiert, muss ich diesen daemon noch irgendwie konfigurieren oder läuft der jetzt einfach

Bert · Beitrag von **Bert** » 21.02.2005 18:48:29

Anacron ist ein cron Ersatz für Rechner welche nicht immer laufen.

Bei Debian richten Packete welche Logdateien anlegen in der Regel auch einen entsprechenden Cron Job an. Dieser ist dann für das Rotieren und komprimieren der Logs zuständig. Anacron sollte also die bereits bestehenden Cron Jobs einfach übernehmen (hat es jedenfalls bei mir)

Allerdings solltest Du mal schauen, was da so in den Logs steht. So viel ich eigentlich normal.. Vielleicht ist ja was falsch konfiguriert?

Gruß Bert

Beitrag von **blackm** » 21.02.2005 19:39:42

unstable....viel Daten in debug.log...passt fuer mich zusammen

pdreker · Beitrag von **pdreker** » 21.02.2005 20:40:10

Naja...

Code: Alles auswählen

$ ls -l /var/log/debug*
-rw-r-----  1 root adm  7964 2005-02-21 13:17 /var/log/debug
-rw-r-----  1 root adm 23243 2005-02-19 12:34 /var/log/debug.0
-rw-r-----  1 root adm  2383 2005-02-12 00:03 /var/log/debug.1.gz
-rw-r-----  1 root adm  2202 2005-02-04 09:52 /var/log/debug.2.gz
-rw-r-----  1 root adm  8269 2005-01-28 21:58 /var/log/debug.3.gz
-rw-r-----  1 root adm   683 2003-11-19 19:18 /var/log/debug.4.gz

Haelt sich bei mir stark in Grenzen, aber kontrollieren, was da so gross geworden ist schadet nicht.

Wenn anacron nicht installiert ist kann es auch sein, dass die Logrotation (die ja die Groesse in Grenzen haelt) nie ausgefuehrt ist, weil der Rechner zu dem betreffenden Zeitpunkt nie eingeschaltet ist...

Patrick

hennes@debian · Beitrag von **hennes@debian** » 21.02.2005 20:47:17

Also bei mir ists nicht viel...
Debian Sarge, 24h/Tag in Betrieb und noch nie gelöscht:
linux-server:/home/hannes# du -hs /var/log/
7.6M /var/log/

Ich würde mal die Logfiles anschauen, ev. produziert ein Prozess massenhaft Fehler...

steven · Beitrag von **steven** » 21.02.2005 21:16:44

ich poste mal paar zeilen aus meiner debug.log und kern.log.
keine ahnung wie ich die einzellnen prozesse dazu bringe nicht soviel output zu erzeugen.

also hier ein paar beispiele aus der debug.log

Code: Alles auswählen

Feb 21 18:35:43 localhost kernel: bridge-eth1: attached
Feb 21 18:35:43 localhost kernel: /dev/vmnet: open called by PID 3233 (vmnet-netifup)
Feb 21 18:35:43 localhost kernel: /dev/vmnet: hub 1 does not exist, allocating memory.
Feb 21 18:35:43 localhost kernel: /dev/vmnet: port on hub 1 successfully opened
Feb 21 21:03:13 localhost kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Feb 21 21:03:13 localhost kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
Feb 21 21:03:13 localhost kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
Feb 21 21:03:13 localhost kernel: Probing IDE interface ide0...
Feb 21 21:03:13 localhost kernel: Probing IDE interface ide1...
Feb 21 21:03:13 localhost kernel: Probing IDE interface ide2...
Feb 21 21:03:13 localhost kernel: ide2: Wait for ready failed before probe !
Feb 21 21:03:13 localhost kernel: Probing IDE interface ide3...
Feb 21 21:03:13 localhost kernel: ide3: Wait for ready failed before probe !
Feb 21 21:03:13 localhost kernel: Probing IDE interface ide4...
Feb 21 21:03:13 localhost kernel: ide4: Wait for ready failed before probe !
Feb 21 21:03:13 localhost kernel: Probing IDE interface ide5...
Feb 21 21:03:13 localhost kernel: ide5: Wait for ready failed before probe !
Feb 21 21:03:13 localhost kernel: hda: cache flushes not supported
Feb 21 21:03:13 localhost kernel: ieee1394: Host added: ID:BUS[0-00:1023]  GUID[00061b0020094d59]
Feb 21 21:03:13 localhost kernel: ieee80211_crypt: registered algorithm 'NULL'
Feb 21 21:03:13 localhost kernel: ieee80211_crypt: registered algorithm 'WEP'
Feb 21 21:03:13 localhost kernel: eth0: Using hotplug firmware load.
Feb 21 21:03:13 localhost kernel: PCI: Setting latency timer of device 0000:00:1f.6 to 64
Feb 21 21:03:13 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
Feb 21 21:03:13 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64
Feb 21 21:03:13 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64
Feb 21 21:03:13 localhost kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64

beispiele aus kern.log:

Code: Alles auswählen

Feb 21 18:35:26 localhost kernel: 767MB LOWMEM available.
Feb 21 18:35:26 localhost kernel: On node 0 totalpages: 196448
Feb 21 18:35:26 localhost kernel:   DMA zone: 4096 pages, LIFO batch:1
Feb 21 18:35:26 localhost kernel:   Normal zone: 192352 pages, LIFO batch:16
Feb 21 18:35:26 localhost kernel:   HighMem zone: 0 pages, LIFO batch:1
Feb 21 18:35:26 localhost kernel: DMI present.
Feb 21 18:35:26 localhost kernel: ACPI: RSDP (v002 IBM                                   ) @ 0x000f6d30
Feb 21 18:35:26 localhost kernel: ACPI: XSDT (v001 IBM    TP-1P    0x00001180  LTP 0x00000000) @ 0x2ff6f23a
Feb 21 18:35:26 localhost kernel: ACPI: FADT (v003 IBM    TP-1P    0x00001180 IBM  0x00000001) @ 0x2ff6f300
Feb 21 18:35:26 localhost kernel: ACPI: SSDT (v001 IBM    TP-1P    0x00001180 MSFT 0x0100000e) @ 0x2ff6f4b4
Feb 21 18:35:26 localhost kernel: ACPI: ECDT (v001 IBM    TP-1P    0x00001180 IBM  0x00000001) @ 0x2ff78e4f
Feb 21 18:35:26 localhost kernel: ACPI: TCPA (v001 IBM    TP-1P    0x00001180 PTL  0x00000001) @ 0x2ff78ea1
Feb 21 18:35:26 localhost kernel: ACPI: BOOT (v001 IBM    TP-1P    0x00001180  LTP 0x00000001) @ 0x2ff78fd8
Feb 21 18:35:26 localhost kernel: ACPI: DSDT (v001 IBM    TP-1P    0x00001180 MSFT 0x0100000e) @ 0x00000000
Feb 21 18:35:26 localhost kernel: Built 1 zonelists
Feb 21 18:35:26 localhost kernel: Kernel command line: root=/dev/hda3 ro resume=/dev/hda5
Feb 21 18:35:26 localhost kernel: Initializing CPU#0
Feb 21 18:35:26 localhost kernel: PID hash table entries: 4096 (order: 12, 65536 bytes)
Feb 21 18:35:26 localhost kernel: Detected 599.603 MHz processor.
Feb 21 18:35:26 localhost kernel: Using tsc for high-res timesource
Feb 21 18:35:26 localhost kernel: Console: colour VGA+ 80x25
Feb 21 18:35:26 localhost kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Feb 21 18:35:26 localhost kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Feb 21 18:35:26 localhost kernel: Memory: 774336k/785792k available (2471k kernel code, 11020k reserved, 941k data, 164k init, 0k highmem)
Feb 21 18:35:26 localhost kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok.
Feb 21 18:35:26 localhost kernel: Calibrating delay loop... 1183.74 BogoMIPS (lpj=591872)
Feb 21 18:35:26 localhost kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Feb 21 18:35:26 localhost kernel: CPU: After generic identify, caps: a7e9f9bf 00000000 00000000 00000000
Feb 21 18:35:26 localhost kernel: CPU: After vendor identify, caps:  a7e9f9bf 00000000 00000000 00000000
Feb 21 18:35:26 localhost kernel: CPU: L1 I cache: 32K, L1 D cache: 32K
Feb 21 18:35:26 localhost kernel: CPU: L2 cache: 1024K
Feb 21 18:35:26 localhost kernel: CPU: After all inits, caps:        a7e9f9bf 00000000 00000000 00000040
Feb 21 18:35:26 localhost kernel: Intel machine check architecture supported.
Feb 21 18:35:26 localhost kernel: Intel machine check reporting enabled on CPU#0.
Feb 21 18:35:26 localhost kernel: CPU: Intel(R) Pentium(R) M processor 1300MHz stepping 05
Feb 21 18:35:26 localhost kernel: Enabling fast FPU save and restore... done.
Feb 21 18:35:26 localhost kernel: Enabling unmasked SIMD FPU exception support... done.
Feb 21 18:35:26 localhost kernel: Checking 'hlt' instruction... OK.
Feb 21 18:35:26 localhost kernel: ACPI: IRQ9 SCI: Edge set to Level Trigger.
Feb 21 18:35:26 localhost kernel: NET: Registered protocol family 16
Feb 21 18:35:26 localhost kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd936, last bus=5
Feb 21 18:35:26 localhost kernel: PCI: Using configuration type 1
Feb 21 18:35:26 localhost kernel: mtrr: v2.0 (20020519)
Feb 21 18:35:26 localhost kernel: ACPI: Subsystem revision 20040816
Feb 21 18:35:26 localhost kernel: ACPI: Found ECDT
Feb 21 18:35:26 localhost kernel: ACPI: Interpreter enabled
Feb 21 18:35:26 localhost kernel: ACPI: Using PIC for interrupt routing
Feb 21 18:35:26 localhost kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
Feb 21 18:35:26 localhost kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)
Feb 21 18:35:26 localhost kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)

Bert · Beitrag von **Bert** » 22.02.2005 08:04:40

Sieht für mich nach boot-Meldungen aus. Soo oft wirst Du das System ja nicht starten, das Du da gleich GB an Logs bekommst.

Welche Dateien sind denn am größten? Irgendwelche sich häufig wiederholenden Meldungen (eventuell Warnungen/Fehler) da drin?

Bert

steven · Beitrag von **steven** » 22.02.2005 11:55:38

stimmt du hast recht.. sind alles nur bootmeldungen

ich glaube das ausgabelevel von meinem wlan modul ist bissl hoch eingestellt. immer wenn das ne verbindung herstellt wird das in meinen log dateien verzeichnet. und da ich 500m von so nem t-online hotspot entfernt wohne , bekomm ich auch immer wieder ne meldung das ne neue verbindung aufgebaut wurde

ich hoffe jetzt einfach mal das der cronjob funzt und die dateien in regelmäßigen abständen gelöscht werden