Bug #235
offen[Bugsink] ErrorException: Warning: file_get_contents(http://localhost:8983/solr/default/update?commit=true): Failed to open stream: HTTP request failed!
0%
Beschreibung
Bugsink: https://bugsink.cytrus.de/issues/issue/3554addb-d36b-4682-a400-79574a09ce26/event/last/
Typ: NEW issue
Projekt: www-rietberg-de
Bugsink Alert
ErrorException: Warning: file_get_contents(http://localhost:8983/solr/default/update?commit=true): Failed to open stream: HTTP request failed!
Automatisch erstellt durch n8n
KI-Analyse:
1. Ursache identifizieren
Die Fehlermeldung
Warning: file_get_contents(http://localhost:8983/solr/default/update?commit=true):
Failed to open stream: HTTP request failed!
zeigt, dass ein PHP‑Aufruf mit file_get_contents() versucht, eine HTTP‑GET‑Anfrage an einen Solr‑Endpoint (http://localhost:8983/solr/default/update?commit=true) zu senden. Der Request schlägt fehl, weil:
- Der Solr‑Server auf
localhost:8983nicht läuft oder nicht erreichbar ist (z. B. wegen falscher Bind‑Adresse, Firewall‑Blockade oder fehlendem Dienst). - Alternativ ist die URL in der TYPO3‑Konfiguration falsch (z. B. falscher Port, fehlendes
/solr‑Kontext‑Pfad). - Der Aufruf erfolgt aus einer Scheduler‑Task heraus (siehe Stack‑Trace:
SchedulerCommand::executeOrStopTask → Scheduler::executeTask). Damit wird wahrscheinlich ein Index‑Commit bzw. ein Optimize‑Befehl an Solr gesendet, wenn ein Scheduler‑Job (z. B. „Solr‑Index aktualisieren“) ausgeführt wird.
2. Fix beschreiben (konkret)
| Schritt | Beschreibung | Code‑/Konfigurationsänderung |
|---|---|---|
| 2.1 Solr‑Verfügbarkeit prüfen | Stellen Sie sicher, dass der Solr‑Daemon auf dem erwarteten Host/Port lauscht. bash<br>netstat -tlnp | grep 8983<br>oder im Solr‑Log nach Start‑Meldungen suchen. |
Keine Code‑Änderung nötig, nur sicherstellen, dass der Dienst läuft. |
| 2.2 Bind‑Adresse korrekt setzen | Falls Solr nur an 127.0.0.1 gebunden ist, aber die TYPO3‑Instanz in einem Docker‑Container oder einer anderen Netzwerk‑Namespace läuft, muss die Adresse angepasst werden. In solr.in.sh (oder solr.in.cmd unter Windows) die Variable SOLR_HOST auf 0.0.0.0 setzen oder explizit auf die IP des Containers. |
SOLR_HOST="0.0.0.0" |
| 2.3 TYPO3‑Solr‑Extension‑Konfiguration anpassen | Prüfen Sie die Extension‑Konfiguration (typischerweise unter Extension Manager > Solr oder in LocalConfiguration.php unter $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['solr']). Stellen Sie sicher, dass host, port und path korrekt sind. Beispiel: |
php<br> $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['solr'] = [\n 'host' => '127.0.0.1', // oder die tatsächliche IP\n 'port' => 8983,\n 'path' => '/solr',\n 'core' => 'default',\n ];\n |
2.4 Aufruf von file_get_contents ersetzen (falls nötig) |
Die Solr‑Extension nutzt veraltet file_get_contents für HTTP‑Requests. Ein robusterer Ansatz ist die Nutzung von \TYPO3\CMS\Core\Http\RequestFactory oder Guzzle. Wenn Sie die Extension selbst anpassen können, ersetzen Sie den Aufruf durch: |
php\n$request = GeneralUtility::makeInstance(RequestFactory::class);\n$response = $request->request(\n 'GET',\n 'http://' . $host . ':' . $port . $path . '/update?commit=true',\n [],\n [],\n ['timeout' => 10] // optional Timeout setzen\n);\nif ($response->getStatusCode() !== 200) {\n throw new \RuntimeException('Solr commit failed: ' . $response->getReasonPhrase());\n}\nFalls Sie die Extension nicht ändern wollen, stellen Sie zumindest sicher, dass allow_url_fopen in php.ini enabled ist und dass kein outgoing‑HTTP‑Block (z. B. tramite suhosin, php_value allow_url_fopen Off oder Firewall) besteht. |
| 2.5 Scheduler‑Task‑Ausführung testen | Nach den Anpassungen den Scheduler‑Task manuell ausführen: bash\nvendor/bin/typo3 scheduler:run\noder über das Backend → Scheduler → Task ausführen. Prüfen Sie das Solr‑Log ( logs/solr.log) auf erfolgreiche Commit‑Antworten. |
Keine weitere Code‑Änderung nötig. |
| 2.6 Monitoring / Fallback | Optional: Im Scheduler‑Task ein Try/Catch um den Solr‑Aufruf legen und bei Failure eine informative Nachricht loggen bzw. per Mail alarmieren, damit zukünftige Ausfälle frühzeitig erkannt werden. | php\ntry {\n // Solr‑Commit\n} catch (\Exception $e) {\n $this->logger->error('Solr commit failed: ' . $e->getMessage());\n // optional: Mail an Admin\n}\n |
3. Betroffene TYPO3 Extension nennen
Der Stack‑Trace führt über SchedulerCommand und endet in TYPO3\\CMS\\Scheduler\\Scheduler::executeTask. Der eigentliche Solr‑Aufruf erfolgt in der TYPO3 Extension „solr“ (offiziell: tx_solr bzw. solr aus dem TER). Diese Extension stellt Scheduler‑Tasks bereit, die den Solr‑Index aktualisieren, committen oder optimieren – genau der Punkt, an dem das file_get_contents‑Statement aufgerufen wird.
Falls Ihr Projekt eine abgeleitete oder forked Solr‑Extension nutzt (z. B. apachesolr, solr von Drittanbietern), liegt der Fehler grundsätzlich ebenfalls dort, weil der Aufrufweg identisch ist.
4. Confidence (0‑100 %)
- 95 % – Die Fehlermeldung, der Stack‑Trace und die konkrete URL zeigen eindeutig auf einen fehlgeschlagenen HTTP‑Request zu einem Solr‑Endpunkt. Die einzige Unsicherheit besteht darin, ob das Problem wirklich beim Solr‑Server liegt oder ob eine falsche Konfiguration (Host/Port/Pfad) vorliegt; beides lässt sich jedoch durch die angegebenen Prüfungsschritte eindeutig verifizieren oder ausschließen.
Kurzfassung für den Entwickler:
Stellen Sie sicher, dass Solr unter http://localhost:8983/solr/default erreichbar ist (Dienst läuft, korrekte Bind‑Adresse, Firewall offen). Prüfen/passen Sie anschließend die Solr‑Extension‑Konfiguration in TYPO3 an (host, port, path, core). Optional ersetzen Sie den veralteten file_get_contents‑Aufruf durch den modernen TYPO3‑Request‑Client bzw. stellen Sie sicher, dass allow_url_fopen aktiviert ist. Nach diesen Schritten sollte der Scheduler‑Task ohne die HTTP‑Fehlermeldung durchlaufen.
Nichts anzuzeigen