☰

Cronjob „Kein Platz mehr auf dem Gerät“ beim Protokollieren eines Fehlers, aber es ist Platz vorhanden

tag-icon • tag-icon linux ubuntu cron
Cronjob „Kein Platz mehr auf dem Gerät“ beim Protokollieren eines Fehlers, aber es ist Platz vorhanden

Ich versuche, einige meiner Cronjob-Probleme zu beheben und wollte daher mit der Protokollierung beginnen.

* * * * * wget https://www.example.com/dosomething.php >> /var/log/myjob.log 2>&1

Wenn ich meine Protokolldatei ansehe, erhalte ich die Fehlermeldung „Kein Speicherplatz mehr auf dem Gerät“, obwohl der Cronjob erfolgreich ausgeführt wird.

Ich habe mein df und df -i geprüft, um meinen Speicher und meine Inodes zu prüfen, und ich habe reichlich Speicherplatz.

Was verursacht diesen speziellen Fehler „Kein Speicherplatz mehr auf dem Gerät“ bei der Protokollierung?

--2022-12-09 19:32:08--  https://www.example.com/dosomething.php
Resolving www.example.com (www.example.com)... x.x.x.x
Connecting to www.example.com (www.example.com)|x.x.x.x|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/html]
dosomething.php.962181: No space left on device

Cannot write to 'dosomething.php.962181' (Success).

Bildbeschreibung hier eingeben

Antwort1

Ich vermute, Siebei jeder Ausführung des Skripts eine neue Datei gespeichertund stoßen auf ein Ressourcenlimitandereals die Gesamtgröße des Dateiinhalts.

Versuchen Sie df -i, die Inode-Nutzung zu ermitteln. Viele Dateisysteme setzen eine Grenze nicht nur für das Gesamtvolumen der DateiInhalt, sondern zusätzlich auf Dateimetadateneinträgen, die zum Speichern von Namen, Besitzer, Zeit, Berechtigungen usw. erforderlich sind. Wenn Sie eine Million Inodes sehen, liegt das deutlich über der üblichen Nutzung durch Betriebssysteme.

Ein solcher Befehl kann für eine unbestimmte Zeit hängen bleiben, aber Sie können versuchen, wahrscheinliche Verzeichnisse direkt zu überprüfen, um festzustellen, ob Sie962181leere Dateien in einem Verzeichnis. Einige Dateisysteme legen zusätzliche Beschränkungen für die Anzahl einzelner Einträge unterhalb einer einzelnen Verzeichnisebene fest. Das ist wahrscheinlich nicht das, was Sie wollen, denn jede Anwendung, bei der viele Dateien erwünscht sind, wäre auch mit einem schnellen (mehrstufig indizierten) Zugriff besser bedient.

Wie gehe ich mit der übermäßigen Anzahl gefundener Dateien um?

Wenn Sie die potenzielle Ausgabe behalten möchten, aber nicht die Zeiten speichern müssen, zu denen Ihr Cronjob zuvor ausgeführt wurde, möchten Sie möglicherweise selektiv leere Dateien löschen und nur weiter untersuchen, was die nicht leeren Dateien sagen, z. B.:

# find /root -xdev -maxdepth 1 -type f -size 0 -name "dosomething.php.*" -delete

Wie kann verhindert werden, dass das Problem in Zukunft erneut auftritt?

Wenn Sie das Ergebnis aller vorherigen Downloads nicht unbedingt speichern müssen, können Sie einen Ausgabenamen angeben (möglicherweise sogar /dev/null, um nicht einmal den letzten Download zu speichern), der bei jedem Aufruf überschrieben wird, im Gegensatz zum Standard, bei demLockehängt einfach eine Nummer an den Ausgabedateinamen an, wenn dieser bereits im Verzeichnis vorhanden ist.

* * * * * wget -O /root/latest-something.html https://example.com/something.php >> /var/log/myjob.log 2>&1

verwandte Informationen