Talk container shows as unhealthy, but everything seems working fine

Hi, since the 5.0.0 update (now on 5.1.0 and same issue) talk container is reporting as unhealthy

I tried running the health check manually and everything seems working, although after running the command the container bash exited to host system, not sure if expected behavior.

My nextcloud server is running behind a proxy, which is configured correctly (verified), I can call from external network to PC on a LAN.

root@MyCloudPR4100 ~ # sudo docker exec -it nextcloud-aio-talk bash
52e509fcc2b8:/$ set -x; (nc -z localhost 8081 && nc -z localhost 8188 && nc -z localhost 4222 && nc -z localhost "$TALK_PORT" && nc -z "$NC_DOMAIN" "$TALK_PORT") || exit 1
+ nc -z localhost 8081
+ nc -z localhost 8188
+ nc -z localhost 4222
+ nc -z localhost 3478
+ nc -z nextcloud.redacted.tld 3478
+ exit 1
root@MyCloudPR4100 ~ #


Logger plugins folder: /usr/lib/janus/loggers
Loading logger plugin ''...
Adding 1 external loggers
[WARN] JSON logger disabled
  Starting Meetecho Janus (WebRTC Server) v1.1.3
Checking command line arguments...
Debug/log level is 4
Debug/log timestamps are disabled
Debug/log colors are disabled
Adding 'vmnet' to the ICE ignore list...
Using as local IP...
Token based authentication disabled
Initializing recorder code
Initializing ICE stuff (Full mode, ICE-TCP candidates disabled, half-trickle, IPv6 support disabled)
TURN REST API backend: (disabled)
[WARN] Janus is deployed on a private address ( but you didn't specify any STUN server! Expect trouble if this is supposed to work over the internet and not just in a LAN...
Crypto: OpenSSL >= 1.1.0
[WARN] The libsrtp installation does not support AES-GCM profiles
No cert/key specified, autogenerating some...
Fingerprint of our certificate: E3:D1:BC:63:80:BF:6B:33:E1:12:98:CE:F5:27:89:69:65:F0:64:D6:AA:1D:8D:31:BC:FC:25:B5:D9:72:9B:5A
Event handlers support disabled
Sessions watchdog started
Joining Janus requests handler thread
Plugins folder: /usr/lib/janus/plugins
Loading plugin ''...
JANUS AudioBridge plugin initialized!
Loading plugin ''...
[echotest.js]  Loading script...
[echotest.js]  Modules folder: /usr/share/janus/duktape
[echotest.js]  Loading module: janus-sdp
[echotest.js]  Module loaded
[echotest.js]  Script loaded
[echotest.js]  Initializing...
[echotest.js]  Initialized
Janus JavaScript plugin (Duktape) initialized!
Loading plugin ''...
JANUS EchoTest plugin initialized!
Loading plugin ''...
[echotest.lua] Loading...
[echotest.lua] Loaded
[echotest.lua] Initializing...
[echotest.lua] Initialized
Janus Lua plugin initialized!
Loading plugin ''...
JANUS NoSIP plugin initialized!
Loading plugin ''...
JANUS Record&Play plugin initialized!
Loading plugin ''...
JANUS SIP plugin initialized!
Loading plugin ''...
JANUS Streaming plugin initialized!
Loading plugin ''...
JANUS TextRoom plugin initialized!
Loading plugin ''...
JANUS VideoCall plugin initialized!
Loading plugin ''...
JANUS VideoRoom plugin initialized!
Transport plugins folder: /usr/lib/janus/transports
Loading transport plugin ''...
HTTP transport timer started
HTTP webserver started (port 8088, /janus path listener)...
JANUS REST (HTTP/HTTPS) transport plugin initialized!
Loading transport plugin ''...
MQTT SSL support disabled
[WARN] MQTT support disabled for both Janus and Admin API, giving up
JANUS MQTT transport plugin destroyed!
[WARN] The 'janus.transport.mqtt' plugin could not be initialized
Loading transport plugin ''...
JANUS Nanomsg transport plugin initialized!
Loading transport plugin ''...
Nanomsg thread started
[WARN] No Unix Sockets server started, giving up...
[WARN] The 'janus.transport.pfunix' plugin could not be initialized
Loading transport plugin ''...
RabbitMQ SSL support disabled
[WARN] RabbitMQ support disabled for both Janus and Admin API, giving up
[WARN] The 'janus.transport.rabbitmq' plugin could not be initialized
Loading transport plugin ''...
libwebsockets logging: 0
Websockets server started (port 8188)...
JANUS WebSockets transport plugin initialized!
WebSockets thread started
mcu_janus.go:294: Connected to Janus WebRTC Server 1.1.3 by Meetecho s.r.l.
mcu_janus.go:300: Found JANUS VideoRoom plugin 0.0.9 by Meetecho s.r.l.
mcu_janus.go:305: Data channels are supported
mcu_janus.go:307: WARNING: Full-Trickle is NOT enabled in Janus!
mcu_janus.go:311: Maximum bandwidth 1048576 bits/sec per publishing stream
mcu_janus.go:312: Maximum bandwidth 2097152 bits/sec per screensharing stream
Creating new session: 4895675491699504; 0x7f1660fac5a0
mcu_janus.go:318: Created Janus session 4895675491699504
Creating new handle in session 4895675491699504: 4538251148605838; 0x7f1660fac5a0 0x7f1661a55630
mcu_janus.go:325: Created Janus handle 4538251148605838
main.go:263: Using janus MCU
hub.go:385: Using a timeout of 10s for MCU requests
backend_server.go:105: No IPs configured for the stats endpoint, only allowing access from
main.go:339: Listening on
1 Like

This reminds me of nextcloud-aio-talk commented "unhealthy" in portainer since last AiO update · nextcloud/all-in-one · Discussion #2463 · GitHub

I’m facing with the same, but I don’t use Cloudflare tunnel for my Nextcloud.

Was there - similar but not quite:

  1. mine is local reverse proxy nginx, not cloudflare.
  2. his last command on manual heath check failed, mine does not ( ```
  • nc -z nextcloud.redacted.tld 3478

Hey corwin_x,

I can see that you’re facing an issue with your Talk container after the recent update. It’s indeed perplexing when the health check reports as unhealthy despite everything appearing fine. Based on the logs you’ve provided, I’d like to offer some guidance.

Firstly, the warning about not specifying any STUN server in your Janus configuration might be a potential source of the problem, especially if you’re trying to use Janus over the internet. I’d recommend looking into configuring a STUN server and adding it to your Janus setup to improve connectivity.

Secondly, you mentioned that the container bash exited to the host system after running the health check manually. This behavior is somewhat unusual and might indicate an issue with your container configuration. Ensure that the container is properly isolated and not experiencing any conflicts with the host system.

Lastly, have you considered checking the firewall settings on both your proxy and Nextcloud server? Sometimes, issues like this can arise due to firewall rules blocking certain ports.

I hope these suggestions help you get closer to resolving the problem…I’ve been puzzling over how to fix this for a long time.

Turns out, I am a dumbass. I had a local static DNS record for my subdomain on the router pointing directly to IP of nginx proxy running on separate machine. Obviously when talk cotainer tried to connect to itself using the url of nextcloud server, ended up on the ip of the reverse proxy server where nothing responds on port 3478.
Deleted the DNS record, let the hairpin NAT handle the traffic, everything works like a charm.
Short between operators headset.