System voll

Support
1

Hallo,

habe das Problem, das auf einmal das System voll war.
Bis heute morgen lief alles einwandfrei und ab 11 Uhr kam ich nicht mehr auf das Webinterface. Habe dann auch rausgefunden, dass die Partition wohl voll ist und die logs soweit wie möglich gelöscht. Nun sind wieder 80% Verfügbar.
derzeit sieht es so aus:

tmpfs 1,0G 14M 1011M 2% /RAMDISK
/dev/sda1 479M 305M 150M 68% /SYSTEM
/dev/sda2 4,4G 820M 3,4G 20% /CUSTOM
/dev/sda3 5,1G 1,5G 3,4G 31% /BACKUP
/dev/cloop 756M 756M 0 100% /FIRMWARE
unionfs 1,0G 14M 1011M 2% /TARGET
unionfs 4,4G 820M 3,4G 20% /TARGET/etc
unionfs 4,4G 820M 3,4G 20% /TARGET/var
df: â/TARGET/dev/.static/devâ: Keine Berechtigung
tmpfs 10M 52K 10M 1% /TARGET/dev
tmpfs 505M 4,0K 505M 1% /TARGET/dev/shm

Es waren wohl zwei riesige Log Dateien. Leider weiß ich nicht mehr genau wo die waren, ich glaube eine war in var/log/asterisk.

daf436a21c3e63000580b27ce3fa3fa04bfd6b3e.jpg1152×648 62.3 KB

Was kann hierfür die Ursache sein? Und wie kann man das verhindern?

Grüße
Andi

2

Ist die RAM und CPU auslastung immernoch auf dem LEvel und schaufelt sich die Festplatte immernoch so zu? Oder hat sich das nach dem Löschen erledigt?

Dein Problem hat wohl schon gestern gegen 15-16 Uhr begonnen. Also muss da irgendwas passiert sein, was zu diesem Fehler geführt hat. Hast du da irgendwas an der Anlage gemacht?

3

Hallo Andi,

im Normalfall werden alle log-Dateien nach unterschiedlichen Gesichtspunkten rotiert, so dass die Platte unter normalen Bedingungen nicht voll wird.
Wenn du die log-Dateien in der Shell gelöscht hast, könntest du versuchen über das Command history herauszubekommen, welche Dateien es waren.

Falls wie du meinst eine unter /var/log/asterisk dabei war, könnte ich mir nur vorstellen, dass dies die messages.log war. Wenn der Debug recht verbose eingestellt ist kann die in kurzer Zeit sehr groß werden. Bitte prüfe hierzu die Einstellungen in der /etc/asterisk/logger.conf. Bzw. in der CLI einen Logger reload durchführen.

Gruß
Markus

4

Hallo,

danke für eure Antworten. Nein an der Anlage wurde seit letzter Woche nichts verändert. Momentan läuft sie wieder so wies sein soll.

Die Messages.log kommt mir bekommt vor, das war eine von den zwei. Hatte über 2GB. Was genau muss ich bei den Einstellungen ändern bzw. prüfen. Bzw wie funktioniert das im CLI?

Vielen Dank

Grüße
Andi

5

In der logger.conf sollte stehen:
[general]

[logfiles]
console => notice,warning,error
messages => notice,warning,error

Du kannst hier dann auch einfach die Telefonie anwenden. Falls die Einträge manuell geändert wurden, sollte wieder alles passen. Wenn Sie über den Commander modifiziert wurden, musst du die Systemeinstellungen anpassen - sys.asterisk.configure.logger wäre der richtige Zweig hierfür.

Gruß

Markus

6

Ich hab soeben das gleiche Problem.

tmpfs on /TARGET/RAM/lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw,relatime)
tmpfs on /SOURCE/RAMDISK type tmpfs (rw,relatime,size=1048576k)
/dev/sda1 on /SYSTEM type ext2 (ro,relatime,errors=continue)
/dev/vg/SHARE on /SOURCE/SHARE type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
/dev/vg/BACKUP on /BACKUP type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
/dev/vg/NODE on /SOURCE/NODE type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
/dev/loop0 on /SOURCE/FIRMWARE type squashfs (ro,relatime)
/dev/loop1 on /SOURCE/LINKS type iso9660 (ro,relatime)
unionfs on /TARGET/RAM type aufs (rw,relatime,si=944be5a7704c51ab)
unionfs on /TARGET/NODE type aufs (rw,relatime,si=944be5a73e9139ab)
unionfs on /TARGET/SHARE type aufs (rw,relatime,si=944be5a73e9131ab)

Aber es scheint nicht an den log Dateien zu liegen.

Hat jemand eine Idee?

Gruss

Flo

7

Guten Morgen Flo,

schau doch bitte mal mittels df -h die Plattenbelegung selbst an. Bzw. anschließend mittels du -h einVerzeichnis wo der Platz verbraucht wird.

Grüße
Markus

8

Sorry wollte eigentlich den df Output posten.

Dateisystem           Size  Used Avail Use% Eingehängt auf
tmpfs                1002M     0 1002M   0% /TARGET/RAM/lib/init/rw
udev                   10M  120K  9,9M   2% /dev
tmpfs                1002M   32M  971M   4% /dev/shm
tmpfs                 1,0G  1,0G     0 100% /SOURCE/RAMDISK
/dev/sda1             3,8G  1,2G  2,5G  32% /SYSTEM
/dev/vg/SHARE          16G  1,4G   14G  10% /SOURCE/SHARE
/dev/vg/BACKUP         27G  173M   25G   1% /BACKUP
/dev/vg/NODE          5,3G  139M  4,9G   3% /SOURCE/NODE
/dev/loop0            487M  487M     0 100% /SOURCE/FIRMWARE
/dev/loop1            356K  356K     0 100% /SOURCE/LINKS
unionfs               1,0G  1,0G     0 100% /TARGET/RAM
unionfs               5,3G  139M  4,9G   3% /TARGET/NODE
unionfs                16G  1,4G   14G  10% /TARGET/SHARE

Es sieht so aus als wäre das tmpfs voll.

9

Hallo Flo,

das Problem mit dem tmpfs sollte mit der 7.06 behoben sein. Bitte auf die Version aktualisieren.

Grüße
Markus

10

Hi Markus,

kann ich ein Update durchführen, obwohl die Festplatte voll ist?

Wie gehe ich vor, um mich wieder anmelden zu können. Wegen der knallvollen Platte ist kein Login möglich.

Danke

Gruss

Flo

11

Hallo Flo,

ein Reboot sollte das Problem mit dem Login beheben. Auf der Shell einloggen und reboot ausführen.
Danach mittels Updater die Anlage auf die aktuelle Version bringen.

Grüße
Markus