Festplatte voll & inodes auf 99%

Hallo,

seit einigen Tagen steht unsere pascom bei der Systemübersicht auf Rot und unter Dienste Status wird die Disk Usage mit folgendem Hinweis angemeckert:
“DISK CRITICAL - free space: /SYSTEM 3101 MB (84% inode=99%): /BACKUP 0 MB (0% inode=99%): /SOURCE/RAMDISK 1023 MB (99% inode=99%): /SOURCE/SHARE 4776 MB (48% inode=97%): /SOURCE/NODE 3183 MB (97% inode=99%):”

Hat jemand einen Tip für mich wie wir das Problem lösen können?
Es handelt sich hierbei um eine virtuelle Pascom Appliance die auf einem VMWare ESX Server läuft.

Danke!

Gruß
D.Jochem

Hallo @djochem,

komisch ist, das /SOURCE/RAMDISK so voll ist. Da gehen nur Dinge hin, die man eigentlich bei unserem Linux nicht anfassen sollte. Etwa wenn man versucht mit “apt-get” Pakete zu installieren, etc.
Wie ist denn die uptime des Systems?

Da es virtuell ist, würde ich erst einmal mutig einen Snapshot (inkl. Ram!) machen und rebooten. Danach musst Du mal kucken wo der Platz verbraucht wird. Ggf. liegen Mitschnitte, Voicemails oder viele Logfiles herum. In älteren Systemen gab es auch Probleme mit übermäßig großen Datenbanken falls SIP per Internet zugänglich gemacht wurde.
Welche Version hast Du denn da am Laufen?

Gruß,

Thomas

Hallo @tweber,

die Appliance-Version ist 17.10. Leider handelt es sich bei dem System auch noch um eine Produktive Appliance bei einem Kunden :frowning:
Die Uptime beträgt aktuell 17 Stunden und 13 Minuten, da ich das System gestern vor dem Erstellen des Posts bereits neu gestartet hatte, was aber leider keine Verbesserung gebracht hat.
Versuche Pakete manuell zu installieren (via apt-get) wurden nicht durchgeführt.

Hier mal ein Auszug von df-h, eventuell hilft das weiter um das Problem einzugrenzen:

admin@pascom:~$ df -h
Dateisystem Größe Benutzt Verf. Verw% Eingehängt auf
tmpfs 1,0G 220K 1,0G 1% /SOURCE/RAMDISK
/dev/sda1 3,8G 556M 3,1G 16% /SYSTEM
/dev/vg/SHARE 11G 4,9G 4,7G 52% /SOURCE/SHARE
/dev/vg/BACKUP 17G 17G 0 100% /BACKUP
/dev/vg/NODE 3,4G 72M 3,2G 3% /SOURCE/NODE
/dev/loop0 415M 415M 0 100% /SOURCE/FIRMWARE
/dev/loop1 358K 358K 0 100% /SOURCE/LINKS
unionfs 1,0G 220K 1,0G 1% /TARGET/RAM
unionfs 3,4G 72M 3,2G 3% /TARGET/NODE
unionfs 11G 4,9G 4,7G 52% /TARGET/SHARE
tmpfs 801M 16K 801M 1% /TARGET/RAM/run
tmpfs 5,0M 0 5,0M 0% /TARGET/RAM/run/lock
devtmpfs 10M 0 10M 0% /dev
tmpfs 2,0G 4,0K 2,0G 1% /TARGET/RAM/run/shm
unionfs 801M 16K 801M 1% /TARGET/RAM/run
unionfs 5,0M 0 5,0M 0% /TARGET/RAM/run/lock
tmpfs 801M 16K 801M 1% /TARGET/RAM/run
tmpfs 5,0M 0 5,0M 0% /TARGET/RAM/run/lock
tmpfs 2,0G 4,0K 2,0G 1% /TARGET/RAM/run/shm
unionfs 11G 4,9G 4,7G 52% /TARGET/SHARE/var/spool/hylafax/etc

Manuelle Anpassungen am System wurden keine durchgeführt und auch ein manuelles Löschen von Dateien wurde noch nicht versucht, da ich ehrlich gesagt auch nicht wirklich weiß was hier wo gefahrlos gelöscht werden kann.

Hier noch ein Auszug von du -h aus den entsprechenden Verzeichnissen die keinen Speicherplatz mehr aufweisen:

admin@pascom:/BACKUP$ du -h
67M ./firmware
125M ./tsk050313/export
125M ./tsk050313
du: kann Verzeichnis „./lost+found“ nicht lesen: Keine Berechtigung
16K ./lost+found
8,4M ./export
4,5G ./root
7,5G ./dbdump
17G .

admin@pascom:/SOURCE/FIRMWARE$ du -h -d1
8,0M ./bin
0 ./dev
du: kann Verzeichnis „./etc/cups/ssl“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./etc/ldap/slapd.d/cn=config“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./etc/ssl/private“ nicht lesen: Keine Berechtigung
3,5M ./etc
0 ./home
123M ./lib
0 ./lib64
0 ./media
0 ./opt
0 ./proc
512 ./run
6,5M ./sbin
0 ./selinux
0 ./srv
0 ./sys
0 ./tmp
979M ./usr
du: kann Verzeichnis „./var/backups/slapd-2.4.31-2+deb7u3“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/cache/ldconfig“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/cache/rsnapshot“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/lib/icinga“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/lib/pengine“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/lib/php5/sessions“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/lib/postgresql/9.4/main“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/log/apache2“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/log/exim4“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/log/icinga“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/log/iptraf“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/log/privoxy“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/log/samba“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/spool/asterisk“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/spool/cron/crontabs“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/spool/cups“ nicht lesen: Keine Berechtigung
du: kann Verzeichnis „./var/spool/exim4“ nicht lesen: Keine Berechtigung
27M ./var
1,2G .

Kannst du nicht einfach eine BackupISO rausziehen und davon neu installieren?
Ich denke das ist die schnellste Möglichkeit das zu fixen.

Gruß Markus

@MarkusSachs, ja die Überlegung hab ich auch bereits angestellt. Da ich mir allerdings nicht sicher war, ob dann die Fehler weiterhin bestehen hab ich diese Lösung vorerst hinten angestellt. Sofern niemand eine direkte Idee hat wie das zu fixen ist, werde ich das am Wochenende im nächtlichen Wartungsfenster machen und hier kurz berichten ob es erfolgreich war.

So, also was auch immer mein System hier veranstaltet hat kann ich nicht wirklich sagen. Nach der Anregung von @MarkusSachs wollte ich das letzte ISO herunterladen. Das System hat mir aber angezeigt, dass dieses vom 27.04.2019 sei. Nachdem ich nun ein neues Backup erstellt habe, ist auf einmal das Problem mit dem freien Speicherplatz weg. Alle Systemstati sind wieder grün, auch im Icinga.
Heute morgen stand noch eine Meldung an, dass das nächtliche automatische Backup fehlgeschlagen sei. So wirklich nachvollziehen kann ich es nicht, aber augenscheinlich ist das Problem damit erst mal erledigt. Ich werde im nächsten Wartungsfenster mal ein Update auf die aktuellste Version durchführen und den Thread ggfs. wieder eröffnen wenn das Problem wieder auftritt.

Danke an alle für die Unterstützung.