www.verl.de

Bugsink: https://bugsink.cytrus.de/issues/issue/23ad585c-dcda-40ce-9d6f-c90f46b7156d/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/wirtschaft-arbeit/gesundh…

Automatisch erstellt durch n8n

KI-Analyse:

1. Ursache identifizieren¶

Race Condition / Timing-Problem im staticfilecache beim Löschen von Cache-Metadaten.

• Was passiert: Die Extension staticfilecache (b13/lochmueller) versucht via unlink(), die Metadaten-Datei index.config.json für einen gecachten Pfad (wirtschaft-arbeit/gesundheitswesen.html) zu löschen.
• Warum es knallt: Die Datei existiert zum Zeitpunkt des Löschversuchs nicht mehr („No such file or directory“).
• Typische Szenarien:
  1. Parallele Requests: Zwei Requests treffen gleichzeitig auf denselben Cache-Eintrag (z. B. Cache-Warmup + regulärer Request, oder zwei Crawler). Request A löscht die Dateien (Data + Config), Request B versucht kurz darauf die Config nochmal zu löschen.
  2. Deployment/CI: Ein Deploy-Script (typo3cms cache:flush oder manuelles rm -rf typo3temp/assets/tx_staticfilecache) hat die Dateien bereits gelöscht, aber ein laufender PHP-Prozess (oder ein Shutdown-Handler) versucht noch aufzuräumen.
  3. Fehlerhafte Logik in der Extension: Der Code prüft nicht via file_exists() oder is_file() vor dem unlink(), sondern verlässt sich darauf, dass die Datei muss da sein.
• Warum der Stacktrace „nutzlos“ aussieht: Der Fehler tritt als Warning (ErrorException via Error Handler) auf. Der Stacktrace zeigt den gerade aktiven Code (TYPO3 Bootstrap Middlewares), nicht den Verursacher. Der unlink() Aufruf passiert wahrscheinlich in einem Shutdown-Handler (register_shutdown_function), einem Destructor oder asynchron via Signal Handler (bei b13/staticfilecache oft beim postProcessRequest / shutdown), nachdem die Middlewares bereits durchlaufen sind.

2. Fix beschreiben (konkret)¶

Datei: typo3conf/ext/staticfilecache/Classes/Service/StaticFileCacheService.php (oder CacheService.php / FileBackend.php je nach Version – suche nach unlink im Kontext von config.json / index.config.json).

Änderung: Defensive Programmierung vor dem unlink().

Code-Beispiel (Patch):

// ALT (fehlerhaft):
unlink($configFilePath);

// NEU (robust):
// @ unterdrückt die Warning, file_exists checkt Race-Condition sicher genug für Cache-Logs
if (is_file($configFilePath)) {
    @unlink($configFilePath);
}
// ODER moderner (PHP 7+):
try {
    unlink($configFilePath);
} catch (\Throwable $e) {
    // Loggen auf Debug-Level, nicht crashen. Datei weg == Ziel erreicht.
    if ($e->getCode() !== 2) { // ENOENT = 2 (No such file or directory)
        GeneralUtility::syslog('staticfilecache', 'Could not delete config: ' . $e->getMessage(), GeneralUtility::SYSLOG_SEVERITY_WARNING);
    }
}

Zusätzliche Empfehlung (Extension-Konfiguration):
Prüfen, ob ignoreErrors oder silentMode in der Extension-Konfig (TSconfig / Settings.yaml) gesetzt werden kann, um Warnings generell zu schlucken (weniger sauber als Code-Fix).

3. Betroffene TYPO3 Extension nennen¶

staticfilecache (Vendor: b13 / lochmueller, Packagist: b13/staticfilecache oder lochmueller/staticfilecache je nach Version).

• Pfad im Fehler: typo3temp/assets/tx_staticfilecache/... bestätigt den Extension Key tx_staticfilecache.

4. Confidence (0-100%)¶

95%

• Hohe Sicherheit: Dateipfad (tx_staticfilecache), Dateiname (index.config.json) und Fehlerart (unlink warning) sind fingerabdruck-spezifisch für diese Extension.
• Restunsicherheit (5%): Der exacte Zeilenkontext im Stacktrace fehlt (Shutdown/Destructor vs. Middleware), aber die Fix-Strategie (Datei-Existenz prüfen / Exception fangen) ist universell für diesen Fehler in dieser Extension korrekt.