Page hangs indefinitely when the phpredis extension is loaded but no Redis server is reachable (`preloadDirectoryFiles`)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- Mezza giornata
- Idoneità per principianti
- 55/100
Direzione di ricerca
Start in preloadDirectoryFiles() in app/Functions/functions.php, which is reached from findAvatar()/findFile() during resources/views/linkstack/modules/meta.blade.php rendering, and check how it chooses Redis via class_exists('Redis'). Redis connection settings live in config/database.php. Reproduce by loading a public profile with the redis extension present and REDIS_HOST pointing at an unreachable address. Done when the page renders promptly without Redis, and the maintainers have agreed on which of the three suggested approaches to take.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe the bug
On shared hosting where the redis PHP extension is installed but no Redis server is available (e.g. OVH shared hosting), the public profile page never loads. The request hangs until the web server kills it (FastCGI idle timeout, 160 s on OVH), and nothing is written to storage/logs/laravel.log.
The hang happens while rendering resources/views/linkstack/modules/meta.blade.php. That view calls findAvatar() / findFile(), which call preloadDirectoryFiles() in app/Functions/functions.php. Because class_exists('Redis') is true, preloadDirectoryFiles() calls Redis::get() / Redis::setex(), which connect to the default REDIS_HOST=127.0.0.1:6379.
On this host, connections to 127.0.0.1:6379 are not refused. They are silently dropped, so each connection attempt blocks until default_socket_timeout (60 s). Several calls in a single page render add up to more than the server timeout. The surrounding try/catch doesn't help because nothing is thrown before the request is killed, and set_time_limit() doesn't apply either, since time spent waiting on a socket isn't counted.
To Reproduce
- Install LinkStack on a host where the
redisPHP extension is loaded but no Redis server listens on127.0.0.1:6379(and connections are dropped rather than refused). - Keep the default
.envvalues (REDIS_HOST=127.0.0.1,REDIS_PORT=6379,CACHE_DRIVER=file). - Open the home page / a public profile page.
- The request hangs until the web server timeout.
Evidence
Trace of the request (logging autoloads, Laravel events and SQL as they happen). The last event before the hang is the meta module:
0.103s SQL 1.1ms select "links".*, "buttons"."name" from "links" inner join "buttons" ...
0.103s event creating: linkstack.linkstack
0.104s event composing: linkstack.linkstack
0.104s event creating: linkstack.modules.meta
0.104s event composing: linkstack.modules.meta
<nothing more until the request is killed>
Standalone check on the same host:
extension redis loaded : YES
class Redis : YES
default_socket_timeout : 60s
connect 127.0.0.1:6379 : 5.00s failed (110 Connection timed out)
Web server log:
AH10141: FastCGI: comm with server ".../index.php" aborted: idle timeout (160 sec)
AH10149: FastCGI: incomplete headers (0 bytes) received from server ".../index.php"
Workaround
Point REDIS_HOST to a non-existent unix socket in .env so the connection fails immediately instead of timing out:
REDIS_HOST=/tmp/no-redis.sock
The exception is then caught, and the page loads normally.
Suggested fix
- Use Redis in
preloadDirectoryFiles()only when it is explicitly enabled (e.g.CACHE_DRIVER=redisor a dedicated.envoption), not just whenever theRedisclass exists, and/or - set a short connect/read timeout on the Redis connection (e.g.
timeout/read_timeoutinconfig/database.php), and/or - after the first failure, stop trying Redis for the rest of the request (memoize the failure in a static variable).
Environment
- LinkStack version:
4.8.6 - PHP: 8.5.7 (same behaviour on 8.3)
- Database: SQLite
- Hosting: OVH shared hosting (Apache + FastCGI),
redisextension loaded, no Redis server
- Lingua principale
- PHP
- Stelle
- 3.9k
- Fork
- 440
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di LinkStackOrg/LinkStack
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
LinkStackOrg/LinkStack#1011 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 62/100
LinkStackOrg/LinkStack#1007 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 44/100
LinkStackOrg/LinkStack#1003 · 1 commento ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 56/100
LinkStackOrg/LinkStack#1002 ·
-
contributor-friendly dependencies enhancement good first issue help wanted javascript needs more work valid
Difficoltà 2/5 1-3 ore Idoneità per principianti 55/100
LinkStackOrg/LinkStack#995 · 1 commento ·
Tutte le issue di LinkStackOrg/LinkStack
Issue simili
-
sync-en
Difficoltà 1/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
coollabsio/coolify#12299 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
Automattic/blocks-engine#3369 ·
I maintainer di solito rispondono entro 1 giorno
-
0. to triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 67/100
roundcube/roundcubemail-docker#478 ·
I maintainer di solito rispondono entro 1 giorno
-
0. Needs triage 35-feedback bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno