Kein Thread allozierbar nach Update auf 2026.4.1

[RBoy]

Ich sehe diese Fehler in den Logs, nachdem ich kürzlich auf 2026.4.1 (e404d9aabc) aktualisiert habe:

Meldung (151769 gemeldete Kopien)

Job-Ausnahme: kann keinen Thread allozieren

Backtrace

/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'Thread.new'
/usr/local/lib/ruby/3.4.0/socket.rb:712:in 'block in Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Array#map'
/usr/local/lib/ruby/3.4.0/socket.rb:710:in 'Socket.tcp_with_fast_fallback'
/usr/local/lib/ruby/3.4.0/socket.rb:661:in 'Socket.tcp'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:122:in 'RedisClient::RubyConnection#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/ruby_connection.rb:48:in 'RedisClient::RubyConnection#initialize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'Class#new'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:849:in 'block in RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client/middlewares.rb:12:in 'RedisClient::BasicMiddleware#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:848:in 'RedisClient#connect'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:824:in 'RedisClient#raw_connection'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:779:in 'RedisClient#ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-client-0.28.0/lib/redis_client.rb:372:in 'RedisClient#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/client.rb:90:in 'Redis::Client#call_v'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/rack-mini-profiler-4.0.1/lib/mini_profiler/profiling_methods.rb:90:in 'block in Redis::Client#profile_method'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:152:in 'block in Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Monitor#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis.rb:151:in 'Redis#send_command'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/redis-5.4.0/lib/redis/commands/keys.rb:256:in 'Redis::Commands::Keys#del'
/var/www/discourse/lib/discourse_redis.rb:168:in 'block in DiscourseRedis#del'
/var/www/discourse/lib/discourse_redis.rb:29:in 'DiscourseRedis.ignore_readonly'
/var/www/discourse/lib/discourse_redis.rb:165:in 'DiscourseRedis#del'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:48:in 'MiniScheduler::DistributedMutex#synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/distributed_mutex.rb:15:in 'MiniScheduler::DistributedMutex.synchronize'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:365:in 'MiniScheduler::Manager#lock'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:316:in 'MiniScheduler::Manager#tick'
/var/www/discourse/vendor/bundle/ruby/3.4.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler.rb:74:in 'block (2 levels) in MiniScheduler.start'

Hostname	ip-172-x-x-x-app
Prozess-ID	286281
Anwendungsversion	3532c825824ee1259628545c7bd5311ecb918009
Aktuelle Datenbank	default
Aktueller Hostname	discussion.mcebuddy2x.com
Meldung	Beim Ticken des Scheduling-Managers
Zeit	19:57 Uhr

[sam (Sam Saffron)]

Dies wäre höchstwahrscheinlich eine Ressourcenbeschränkung auf Ihrem Server. Was macht der Arbeitsspeicher (RAM) gerade? Haben Sie Details über den Droplet, auf dem Sie laufen?

[RBoy]

Es handelt sich um eine dedizierte Maschine, auf der nur eine Instanz von Discourse läuft. Es scheint keinen Mangel an RAM oder Swap-Speicher zu geben.

[sam (Sam Saffron)]

Wann hast du Docker, das Betriebssystem und das Discourse-Image zuletzt aktualisiert? Läuft alles auf dem neuesten Stand?

[RBoy]

Letzte Woche wurde ein CLI-/Docker-Upgrade und ein OS-Update durchgeführt. Ich werde es erneut versuchen.

Es lief in der Beta-Version vor einigen Wochen problemlos. Dies trat nach dem Update von Beta auf Release über die Browser-Upgrade-Option auf.

[Ethsim2 (Ethan)]

Könntest du ./launcher enter app ausführen und

ulimit -u

Dies zeigt die maximale Anzahl erlaubter Benutzerprozesse/-threads an.

ulimit -a

Dies zeigt alle Ressourcenlimits an.

cat /sys/fs/cgroup/pids.max

Damit wird die maximale Anzahl von Prozessen (PIDs) überprüft, die für den Container oder das System-cgroup erlaubt sind.

---

Verwende nun logout, um zum Host zurückzukehren;

systemctl show docker | grep TasksMax

Damit wird überprüft, ob systemd eine Aufgaben-/Thread-Begrenzung für den Docker-Dienst festgelegt hat.

systemctl show containerd | grep TasksMax

Dies führt eine ähnliche Überprüfung durch, jedoch für den containerd-Dienst anstelle von Docker direkt.

docker inspect app | grep -i pid

Damit werden die Prozess-/PID-Limits und -Einstellungen deines Discourse-Containers überprüft. Der Befehl grep -i pid filtert alle Einträge, die „pid“ enthalten (ohne Berücksichtigung der Groß-/Kleinschreibung).

Falls du weiterhin Fehler erhältst, könntest du bitte die Ausgabe dieser Befehle hier einfügen? Das wäre sehr hilfreich.

[Lilly (Lillian)]

@Ethsim2

könntest du .\launcher enter app eingeben und

./launcher enter app

[RBoy]

Hier sind die Informationen, im Grunde ist alles unbegrenzt

[RBoy]

Ein Neuaufbau über die CLI hat das Problem anscheinend behoben. Ich werde es weiter beobachten. Etwas im Zusammenhang mit dem Browser-Update von der Beta- zur stabilen Version in der letzten Woche hat dies ausgelöst.

Sollten Grenzen für das Browser-Upgrade bestehen? Kann das Browser-Upgrade potenzielle Probleme erkennen, kennzeichnen oder verhindern, dass das Upgrade ausgelöst wird?

[Ethsim2 (Ethan)]

Der Neustart hat wahrscheinlich die cgroup-Platzierung des Containers zurückgesetzt, was erklärt, warum er wieder stabil läuft.

Angesichts der ursprünglichen Fehlermeldung „can’t alloc thread