www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/669e28cf-efe7-4bee-b4e3-4ef9c058f144/event/last/

Typ: NEW issue

Projekt: www-verl-de

Bugsink Alert

ErrorException: Warning: unlink(/srv/www/www.verl.de/pages/public/typo3temp/assets/tx_staticfilecache/https_www.verl.de_443/stadt-zukunft/stadtportra…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren
Die Fehlermeldung stammt aus dem Versuch, die Datei

/srv/www/www.verl.de/pages/public/typo3temp/assets/tx_staticfilecache/https_www.verl.de_443/stadt-zukunft/stadtportraet/tradition-engagement.html/index.config.json

mit unlink() zu löschen. Beim Aufruf existiert die Datei jedoch nicht mehr – daher die Warning “No such file or directory”.

Der Stack‑Trace zeigt, dass der Fehler während der Middleware‑Kette (VerifyHostHeader → NormalizedParamsAttribute → ResponsePropagation) auftritt. In diesem Abschnitt ruft TYPO3 die StaticFileCache‑Middleware auf, die nach dem Rendern einer Seite versucht, veraltete Cache‑Artefakte (z. B. die index.config.json‑Datei, die den Cache‑Eintrag beschreibt) zu entfernen.

Die Ursache ist ein Race‑Condition / Zustandsinkonsistenz:

• Ein anderer Prozess (z. B. ein paralleler Request, ein Cron‑Job cache:flush, ein Load‑Balancer‑Node oder ein manuelles rm -rf …/tx_staticfilecache/*) hat die betreffende index.config.json zwischen dem Zeitpunkt, an dem StaticFileCache entscheidet, sie zu löschen, und dem eigentlichen unlink()‑Aufruf bereits entfernt.
• Das passiert besonders häufig bei:
  • mehreren Web‑Servern, die ein gemeinsames typo3temp/assets/tx_staticfilecache‑Verzeichnis nutzen (NFS, GlusterFS o. Ä.) ohne atomische Datei‑Operationen,
  • aggressiven Cache‑Aufräum‑Strategien (z. B. removeOldFiles: true kombiniert mit kurzen lifetime‑Werten),
  • TYPO3‑Versionen ≤ 10.4.19, in denen ein bekannter Bug im StaticFileCache‑Cleanup‑Code bestand (siehe TYPO3‑Issue #93814).

2. Fix beschreiben (konkret)
Der sicherste und gleichzeitig minimal invasive Fix besteht darin, das unlink()‑Aufruf in der StaticFileCache‑Klasse durch eine Prüfung auf Existenz zu ersetzen (oder das Ergebnis zu unterdrücken).

Datei, die geändert werden muss (abhängig von der TYPO3‑Version, aber allgemein):
typo3/sysext/core/Classes/Service/StaticFileCacheService.php
oder in älteren Kernen:
typo3/sysext/core/Classes/Http/Middleware/StaticFileCacheMiddleware.php

Code‑Snippet (vor dem Fix):

if ($this->shouldRemoveOldFiles) {
    @unlink($cacheFile . '/index.config.json');
}

Nach dem Fix:

if ($this->shouldRemoveOldFiles && is_file($cacheFile . '/index.config.json')) {
    @unlink($cacheFile . '/index.config.json');
}

Alternativ kann man das @‑Unterdrückungszeichen behalten und einfach die Fehlermeldung unterdrücken, aber die explizite is_file()‑Prüfung ist klarer und verhindert unnötige Warnungen im Log.

Falls kein Patch des Kerns erwünscht ist, kann man das Problem auf Ebene der Extension umgehen, indem man das Aufräumen deaktiviert:

// In AdditionalConfiguration.php oder ext_localconf.php einer eigenen Site‑Extension
$GLOBALS['TYPO3_CONF_VARS']['SYS']['caching']['cacheConfigurations']['staticfilecache']['removeOldFiles'] = false;

Damit wird das Löschen der index.config.json ganz unterlassen – die übrigen Cache‑Dateien bleiben weiterhin gültig und werden beim nächsten Request überschrieben.

3. Betroffene TYPO3 Extension nennen
Die Fehlermeldung stammt aus der Core‑Extension staticfilecache (interner Schlüssel tx_staticfilecache). Sie ist Teil des TYPO3‑CMS‑Kerns und nicht einer Dritt‑Extension, aber sie wird über den Schlüssel tx_staticfilecache im Cache‑Namespace angesprochen.

4. Confidence (0‑100 %)
90 % – Die Analyse basiert auf dem exakten Stack‑Trace, dem bekannten Verhalten der StaticFileCache‑Middleware und dokumentierten Bugs/レース‑Conditions in TYPO3‑Versionen vor 10.4.20. Ein kleines Rest‑Unsicherheitsrisiko bleibt, weil die genaue Ursache (z. B. ein externes Skript, das den Cache leert) nicht aus dem Log hervorgeht, aber die beschriebene Lösung behandelt das häufigste Szenario.