Fehlermeldung beim aufrufen der CMDB: No space left on device

[C.Geist]

Hallo,
wenn ich unsere CMDB aufrufe bekomme ich folgende Meldung:
The stream or file "/var/www/html//log/exception_2025-01-23.log" could not be opened in append mode: Failed to open stream: No space left on device
The exception occurred while attempting to log: Database error : No such file or directory

In file: /var/www/html/src/classes/components/isys_component_database_mysqli.class.php (line: 612)

• isys_component_database_mysqli->reconnect
  in file: /var/www/html/src/classes/components/isys_component_database_mysqli.class.php (line: 549)
• isys_component_database_mysqli->query
  in file: /var/www/html/src/classes/components/isys_component_database_mysqli.class.php (line: 709)
• isys_component_database_mysqli->connect
  in file: /var/www/html/src/classes/components/isys_component_database_mysqli.class.php (line: 734)
• isys_component_database_mysqli->__construct
  in file: /var/www/html/src/classes/components/isys_component_database.class.php (line: 322)
• isys_component_database::get_database
  in file: /var/www/html/src/classes/components/isys_component_database.class.php (line: 343)
• isys_component_database::factory
  in file: /var/www/html/src/classes/core/isys_application.class.php (line: 216)
• isys_application->bootstrap
  in file: /var/www/html/src/bootstrap.inc.php (line: 76)
• include_once
  in file: /var/www/html/index.php (line: 95)

Ich bin jetzt kein Linux / Unix Fachmann aber wenn ich mir in der Shell den freien Speicherplatz anzeigen lasse ist noch rund die Hälfte frei.
Wenn ich aus dem Verzeichnis /var/www/html//log/ alte log Dateien gelöscht habe, lief die CMDB wieder für ein paar Stunden, danach wieder das Gleiche.
Jetzt habe ich keine logs mehr zum löschen und die neuen .log Dateien sind auch nicht sonderlich groß.
Ich weiß also wirklich nicht woran es liegt.
Hat vielleicht jemand einen Tipp was ich tun kann?

Grüße Christian

[LFischer]

Hallo @C-Geist

zum Speicherplatzproblem kann ich dir leider nicht viel sagen - das wird vermutlich irgendwo an deiner Umgebung liegen (bin auch kein Linux Fachmann)... Für mich (als Entwickler) wäre es interessanter zu wissen wieso das Exception Log so schnell so groß wird - das klingt für mich als gäbe es einige Fehler in deinem System

Oder ist die Ursache dieser Fehler das nicht mehr auf die Platte geschrieben werden kann?

Viele Grüße
Leo

[Michael Huhn]

@C-Geist

wenn du dich nicht so gut auskennst, dann kann dir ncdu helfen. Das lässt sich ggf. für deine System einfach über den Paketmanager installieren.Damit lässt sich einfach prüfen welche Dateien viel Speicherplatz verbrauchen.

[StefanP74]

Servus,

was gibt den df -h aus?
Was meinst du mit "rund die hälfte frei"?

Es ist genügend Platz frei, auch wenn die Fehlermeldung bezüglich zu wenig Speicherplatz hochkommt?
Was steht denn in dem Log, das angemeckert wird .... bzw. gibt es ein Log das massiv anwächst?

Du hast alle logs aus /var/www/html/log gelöscht und die Meldung kommt dennoch?
Sobald die Meldung hochkommt, was sagt dann df -h ?
Was sagt

du -ah . | sort -rh | head -n 10

Der Befehl gibt die 10 größten Dateien im aktuellen Verzeichnis aus.

Ist das eine neue Installation? Oder schön länger im Betrieb?

[C.Geist]

Hallo und Danke für die Antworten.

Bei mir war leider viel „echte Arbeit“ auf dem Tisch und ich hatte keine Zeit mich um das Sorgenkind CMDB zu kümmern.

Wir benutzen die CMDB seit 2018, die aktuelle VM läuft seit Anfang 2023.
Von dem IT-Dienstleister der der die CMDB eingerichtet und Umgezogen hat haben wir uns Ende 2023 getrennt. Unser neuer IT-Dienstleister kennt die idoit CMDB leider nicht.
Da ich die CMDB hauptsächlich „gefüttert“ habe und mich hier noch am ehesten mit Computern auskenne sollte ich einen Blick drauf werfen.

Ich habe Screenshots von den gewünschten Befehlen angehängt

Also für mich sieht es eigentlich so aus, dass genügend Platz frei ist und die Exception Logs sind und waren auch nicht größer als 4K.

ncdu habe ich jetzt noch nicht getestet, falls es noch Anlass dazu, gibt kann ich es aber probieren.

Nach einem Neustart der VM zeigte die Seite übrigens nur noch Database error.
Das hatten wir im März 21 schon mal, also auf dem alten System, da schrieb der Techniker leider sehr knapp:

„CMDB läuft wieder. Die Datenbank konnte ein Log File nicht schreiben. Löschen und Neuanlage hat das Problem behoben.
Musste ein wenig recherchieren…..“

Das könnte jetzt wieder das selbe Problem sein, ist nur die Frage was ich löschen und neu Anlegen muss?

Grüße Christian

[StefanP74]

Servus @C.Geist

Wenn es kein dynamisches Volume ist:

1. Sag dem Admin er soll nicht so knausrig sein.
2. Läuft die dB-Instanz auf der selben VM wie die App?

Wenn /dev/sda1 das Volume ist, auf dem das OS und i-doit samt dB läuft (aber auch ohne dB), dann ist das nicht gut - dass das Volume vollläuft, liegt auf der Hand. Aus Erfahrung kann ich erhobenen Hauptes sagen, da sind Probleme vorprogrammiert.

zB. würde bei mir schon durch das tägliche Backup das Volume bei dem geringen freien Platz vollaufen.

LG Stefan

[C.Geist]

Servus @StefanP74

zu 1. Uns ist schon aufgefallen dass unser alter Admin sehr sparsam mit dem Speicher war trotz großem Storage.

zu 2. Ich vermute ja, es ist auf jeden Fall die einzige VM die der CMDB zugeordnet ist.

Wie gesagt ich bin kein Linux Profi, aber ich vermute das alles auf /dev/sda1 läuft.
Ich verstehe deinen Punkt mit dem begrenzten Diskspace, aber warum kann die CMDB kein 4K log schreiben wenn noch 8,3G frei sind?
Vor löschen der alten Logs, als die Meldung zum ersten Mal kam, lag die Usage von /dev/sda1 auch in den 50ern,
das verstehe ich halt nicht.

Grüße Christian

[StefanP74]

@C.Geist
die Frage ist, ob zu diesem Zeitpunkt denn auch der dafür vorgesehene Platz frei war, es keine Dateibeschädigungen gibt, das Volume als solches OK ist, andere Prozesse zufällig auch schreiben wollen, es aber nicht können ...
Es muss ja einen Grund dafür geben. Das Sys-Log sollte dabei an sich weiterhelfen ... bzw. weiterführende Logs.

Sagen wir mal so, meine debian Server, die WEB-Services zur Verfügung stellen, sehen alle gleich aus:

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
...
/dev/sda2       124G     25G   93G   22% /
...

Somit auch das System, auf dem i-doit läuft.
Das ist in meinen Augen eine sehr gute Ausgangsposition.
Natürlich kann man das anders sehen und das Volume kleiner halten ... doch unter 85GB gab es in meinen Umgebungen, die ich den letzten ... hmmmm sagen wir 10 Jahren betreute, keine Produktivsysteme - seit 2022 sind es im Standard bei mir 128GB (verteilt auf die bei der Einrichtung von Debian empfohlenen Partitionsgrößen).
Ja, das ist jetzt IT-Philosophie, klarer Fall, ist einfach meine Meinung und fahre damit perfekto.

LG Stefan

[MartinV]

@C.Geist said:

Wie gesagt ich bin kein Linux Profi, aber ich vermute das alles auf /dev/sda1 läuft.

Ja, der root-Mountpoint / ist /dev/sda1. Nur den musst Du Dir anschauen.

Ich verstehe deinen Punkt mit dem begrenzten Diskspace, aber warum kann die CMDB kein 4K log schreiben wenn noch 8,3G frei sind?

Bei Linux-Filesystemen können es auch immer die inodes sein, die knapp werden. Wie die Situation da aussieht, siehst Du mit df -i /

HTH,
Martin

[C.Geist]

Danke @MartinV

Sieht aus als wären die Inodes das Problem:

Was kann ich jetzt tun?

Grüße Christian

[MartinV]

@C.Geist said:

Danke @MartinV

Sieht aus als wären die Inodes das Problem:
Was kann ich jetzt tun?

Kurz gesagt: Du hast zuviele Dateien im System.

Tante Google verweist zum Thema "linux inodes full" auf Stackoverflow Link1 und Link2.

Es gibt mehrere Kommandos, welche die Verzeichnisse mit den meisten Dateien anzeigen, z.B.

for i in $(find / -type d); do echo $(ls -a $i 2>/dev/null | wc -l) $i; done | sort -n

Falls man entbehrliche Dateien findet (wie bei mir in /var/lib/php/sessions mit 17336 Dateien !), kann man durch Löschen Inodes freischaufeln.

[C.Geist]

Danke @MartinV

Die Seite von Tante Google hatte ich in der Zwischenzeit auch gefunden, nur konnte der Befehl mangels Speicher bei mir nicht ausgeführt werden.

sudo find . -xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -n

Dein Befehl funktioniert

Ich weiß jetzt allerdings nicht welche Dateien ich löschen könnte, aus diesem oder einem anderen Ordner.

Die Frage ist auch eigentlich was uns "über Nacht" die CMDB bis zum Max zumüllt, weil auch nach dem löschen dutzender Logs aus var/www/html//log funktionierte die CMDB am nächsten Morgen nicht mehr, ohne das jemand darin gearbeitet hat.

Grüße Christian

P.S.: var/lib/php/sessions ist bei mir leer

[MartinV]

An /var/lib/dpkg würde ich nur mit dem dpkg- oder apt-Befehl indirekt rangehen.

Allerdings kannst Du /var/www/html/updates/versions komplett leermachen - das sind die ausgepackten Dateien für idoit-Updates. Da kommen - in der Anzeige verteilt auf die Unterordner - auch nicht wenige Inodes zusammen.

Was die Platte über Nacht voll macht, kann ich Dir aber auch nicht sagen (und wüßte auch nicht, wie man das herausfinden kann). Sorry.