Wenn auf der Disk in GB Speicherplatz vorhanden ist, aber keine neuen Dateien erstellt werden können, kann der Inode erschöpft sein. Diese Anleitung analysiert die Disk-Kapazität, den Inode, die Quota, /tmp, Log, Sicherung, Mail-Spool, MySQL-Binärlog und gelöschte offene Dateien, ohne Datenverlust zu verursachen.
No space left on device
Disk quota exceeded
Can't create/write to file '/tmp/#sql...' (Errcode: 28)
Filesystem Inodes IUsed IFree IUse%
/dev/sda1 10.0M 10.0M 0 100%
Linux-Dateisysteme verwenden sowohl Datenblöcke als auch Inode-Einträge. Große Dateien können nicht geschrieben werden, wenn die Datenblöcke voll sind; neue Dateien oder Verzeichnisse können auch nicht erstellt werden, wenn die Inode-Einträge erschöpft sind.
df -h zeigt die Kapazität eines Mount-Punkts, nur die Wurzelpartition zu prüken kann zu falschen Ergebnissen führen, wenn /home, /var, /tmp oder ein Sicherungsdisk ein separates Mount-Punkt ist.
df -i zeigt die Inode-Nutzung an. Millionen kleine Sitzung, Cache, Mail, tmp- oder Schadsoftware-Dateien können die Inode verbrauchen und 500/503-Fehler, MySQL- und Mail-Fehler verursachen.
Wenn eine Datei gelöscht wurde, aber ein laufender Prozess den Dateideskriptor noch geöffnet hält, bleibt der Speicherplatz im df-Ausgabe gefüllt. `lsof +L1` findet diese versteckte Speicherplatznutzung; der Speicherplatz wird freigegeben, wenn der Prozess kontrolliert neu gestartet wird.
cPanel-Konto-Quota ist von der vollem Diskplatz unterschieden. Wenn nur ein Benutzer Disk quota exceeded erhält, wird das Konto-Quota und die Quota-Datenbank überprüft; wenn der gesamte Server betroffen ist, hat der volle Montagepriorität.
Anstatt das größteste Datei zu löschen, bestimmen Sie, wofür es verwendet wird. Ohne Prüfungle löschen Sie eine aktive MySQL, einen E-Mail-Spool, einen cPanel-Backup oder ein Systemprotokoll, was zu Datenverlust und Dienstunterbrechungen führen kann.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Das zugehörige Dateisystem kann neue Daten oder Inodes nicht allozieren.
Mögliche Ursache: Festplattenblöcke sind voll, Inode 100% oder zugewiesener Speicherplatz-Grenzwert.
Bedeutung: Von der Anwendung oder MariaDB-Betriebssystem fehlgeschlagen, Daten zu erhalten.
Mögliche Ursache: Fülle von Disk/Inode, /tmp oder Quota.
Bedeutung: Der Benutzer oder die Gruppe hat die zugewiesene Quotengrenze überschritten.
Mögliche Ursache: cPanel-Kontoquote ist voll, Quotendatenbank ist fehlerhaft oder Benutzerdateien haben sich vergrößert.
Bedeutung: Das Dateisystem kann keinen Inode-Verzeichniseintrag für eine neue Datei zuweisen.
Mögliche Ursache: Millionen kleine Cache-, Sitzungs-, Mail-, tmp- oder schädliche Dateien.
Bedeutung: Die Anwendung kann keine Datei im temporären Verzeichnis erstellen.
Mögliche Ursache: /tmp-Bereich/Inode voll, Berechtigung 1777 fehlerhaft oder tmpfs-Grenze.
Bedeutung: Die gelöschte Datei wird vom Prozess offen gehalten.
Mögliche Ursache: Nach der Protokollrotation kann Apache, PHP, MySQL oder ein anderes Daemon ein altes Datei offen halten.
Bedeutung: Paket-Manager, konnte keine MySQL- oder Anwendungs- temporäre Datei erstellen.
Mögliche Ursache: /tmp, /var/tmp oder Wurzeldateisystem voll; Berechtigungs- oder Montage-noexec-Probleme.
Bedeutung: Die E-Mail-Warteschlange oder Spam-Mitteilungen haben sich auf /var/spool/exim aufgebläht.
Mögliche Ursache: Spam sendende Konto, nicht zugestellte E-Mail oder Remote-Server-Probleme.
Bedeutung: Auf dem Ziel für die Sicherungskopie ist nicht genügend Platz für eine neue Sicherungskopie.
Mögliche Ursache: Retention hoch, fehlgeschlagene alte Sicherungen, Remote-Ziel nicht montiert oder lokaler Failover.
Bedeutung: Binary-Log-Retention wird nicht angewendet, wodurch sich Logs ansammeln.
Mögliche Ursache: expire_logs_days/binlog_expire_logs_seconds ist fehlend oder nicht aufgrund der Replikationsanforderung gelöscht worden.
Bedeutung: EXT-Dateisystem getrennte Blöcke können nur für den Root verbleiben.
Mögliche Ursache: Die Festplatte hat den kritischen Schwellenwert erreicht; normale Benutzer können den zugewiesenen Speicherplatz nicht nutzen.
Bedeutung: Das Dateisystem kann nach einem Fehler aus Sicherheitsgründen nur lesbar gemountet werden.
Mögliche Ursache: Disk/I/O-Fehler, Dateisystemkorruption oder Kernel-Neumount.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
df -hT
lsblk -f
Zeigt die Kapazität, den Typ und die zugehörige Festplatte aller Mount-Punkte an.
df -ih
Es zeigt, welcher Dateisystem keine inode mehr hat.
du -xhd1 / 2>/dev/null | sort -h | tail -n 25
du -xhd1 /var 2>/dev/null | sort -h | tail -n 25
du -xhd1 /home 2>/dev/null | sort -h | tail -n 25
Findet übergeordnete Verzeichnisse, die den Speicherplatz innerhalb des gleichen Dateisystems erhöhen
find /var /home -xdev -type f -size +500M -printf '%s %p\n' 2>/dev/null | sort -n | tail -n 50 | numfmt --field=1 --to=iec
Listet große Dateien über 500 MB nach Größe auf.
for d in /var/* /home/*; do [ -d "$d" ] && printf '%10s %s\n' "$(find "$d" -xdev -type f 2>/dev/null | wc -l)" "$d"; done | sort -n | tail -n 30
Inode-verbrauchende Elterndirektoren sind nach Dateianzahl sortiert.
lsof +L1 2>/dev/null | sort -k7 -n | tail -n 50
Zeigt Dateien, die trotzdem durch den Prozess offen gehalten werden, obwohl sie gelöscht wurden.
du -xsh /var/spool/exim /backup /home/*/backup* 2>/dev/null
exim -bpc 2>/dev/null
Exim überprüft die Größe der Warteschlange und der gängigen Backup-Orte.
du -xsh /var/lib/mysql 2>/dev/null
find /var/lib/mysql -maxdepth 1 -type f -printf '%s %p\n' 2>/dev/null | sort -n | tail -n 30 | numfmt --field=1 --to=iec
Listet große Log- und Datenfiles im MariaDB-Datenvorrat auf.
Bestimmen Sie zunächst den korrekten Mount-Punkt und den Typ der Nutzung; finden Sie dann den Dienst oder das Konto, der bzw. das das Wachstum verursacht hat, führen Sie eine sichere Bereinigung durch und verhindern Sie, dass es erneut passiert.
df -h zeigt die Kapazität des Mount-Punkts und df -i zeigt die Inode, bestimmen Sie, welcher Mount-Punkt sich im Fehlermeldung befindet.
df -hT
df -ih
df -hT /tmp /var /home /backup 2>/dev/nullVerwenden Sie -xdev mit den find-Befehlen, um den ursprünglichen Quellcode ohne Umzug zwischen Montagen zu finden.
du -xhd1 /var 2>/dev/null | sort -h | tail -n 25Bevor Sie löschen, bestimmen Sie, welcher Service oder cPanel-Account die Datei gehört, und ob sie aktiv ist oder nicht, und ob ein Backup existiert oder nicht.
stat /YOL/DOSYA
lsof /YOL/DOSYA 2>/dev/nullLogs sollten mit logrotate, MySQL-Binary-Logs mit dem SQL-PURGE-Befehl, cPanel-Backups mit der Retentions-Einstellung und der E-Mail-Warteschlange-Analyse gelöscht werden.
logrotate -d /etc/logrotate.conf 2>&1 | tail -n 80Neustarten Sie den Dienst, der das große Datei in der lsof +L1-Ausgabe besitzt, mithilfe des cPanel-Skripts oder systemctl.
lsof +L1 2>/dev/null | sort -k7 -n | tail -n 30Verme der WHM-Speicherplatznutzungsschwelle, Backup-Retention, logrotate und MySQL-Binary-Log-Zeit anpassen, um Wiederholungen zu verhindern.
df -hT
df -ihDie wahrscheinlichste Ursache ist die Inode-Prozentzahl 100 oder die Kontingentierung. Vergleichen Sie die Ausgabe von df -i und repquota.
df -ih
repquota -a 2>/dev/null | head -n 80Der Prozess könnte die gelöschte Datei noch halten. Mit lsof +L1 wird der PID gefunden und der zugehörige Dienst wird unter Prüfungle neu gestartet.
lsof +L1 2>/dev/null | sort -k7 -n | tail -n 50Das Konto, das Spam-Nachrichten gesendet hat, gefrorene Nachrichten und Lieferfehler werden vor dem Löschnen der Warteschlange identifiziert. Wenn der Grund nicht behoben wird, wird die Warteschlange wieder aufgefüllt.
exim -bpc
exim -bp | exiqsumm | head -n 60Wenn Replication verwendet wird, wird die Slave-Position überprüft. Eine sichere Bereinigung wird innerhalb von MariaDB mit PURGE BINARY LOGS durchgeführt.
mysql -e "SHOW BINARY LOGS; SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';"Daten können in den lokalen Ordner geschrieben worden sein, wenn der entfernte Zielort nicht montiert wurde. Die Aufbewahrung, unvollständige Sicherungskopien und remote Transport-Protokolle werden überprüft.
mount | grep -E '/backup|backup'
du -h --max-depth=2 /backup 2>/dev/null | sort -h | tail -n 30Es zeigt an, dass in dem zugehörigen Dateisystem keine Datenblöcke oder Inodes mehr vorhanden sind. Der Fehlerort sollte an der Montagestelle mit df -h und df -i überprüft werden.
Inode kann 100% sein oder der Benutzerquota ist voll. Die Festplattencapazität und Inode sind separate Ressourcen.
Dateisystemmetadatensatz für jede Datei und jeden Verzeichnisseintrag. Eine große Anzahl kleiner Dateien kann Inodes verbrauchen, bevor der Festplattenspeicher aufgebraucht ist.
find ile üst dizinler altındaki dosya sayıları karşılaştırılır. Cache, session, mail ve tmp klasörleri özellikle incelenir.
Ein laufender Prozess könnte die gelöschte Datei offen halten. Mit lsof +L1 kann er ermittelt werden und der zugehörige Dienst wird neu gestartet, wenn das Gebiet frei wird.
Nein. Die Log-Index-Datenbank von MariaDB kann beschädigt und die Replikation beeinträchtigt werden. Die Befehle SHOW BINARY LOGS und PURGE BINARY LOGS müssen verwendet werden.
Nein. Die Kontingente der Konten zeigen die erlaubte Nutzung eines einzelnen Benutzers, df zeigt die physische Kapazität des gesamten Dateisystems.
Es variiert je nach Last; jedoch sollte ein sicheres Anteil zur Produktion von Alarms vor Erreichen des kritischen Schwellenwerts für Datenbank, Log und Backupwachstum zugewiesen werden.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.