Dashboard takes 10 min to load

Hey there,

been using Node-RED for literally years now, and this never happened to me:

I noticed, that the docker container was unhealthy. Checking the logs, I only got this at first:

16 Dec 20:41:01 - [info] 
Welcome to Node-RED
16 Dec 20:41:01 - [info] Node-RED version: v3.0.2
16 Dec 20:41:01 - [info] Node.js  version: v16.16.0
16 Dec 20:41:01 - [info] Linux 5.4.0-135-generic x64 LE
16 Dec 20:41:11 - [info] Loading palette nodes

Ten minutes later, the dashboard has finally loaded, but I cannot really figure out, whats the problem here (there are some errors though):

16 Dec 20:50:46 - [info] Dashboard version 3.1.7 started at /ui
16 Dec 20:50:48 - [info] Settings file  : /data/settings.js
16 Dec 20:50:48 - [info] Context store  : 'default' [module=memory]
16 Dec 20:50:48 - [info] User directory : /data
16 Dec 20:50:48 - [warn] Projects disabled : editorTheme.projects.enabled=false
16 Dec 20:50:48 - [info] Flows file     : /data/flows.json
16 Dec 20:50:50 - [info] Server now running at
16 Dec 20:50:50 - [warn] 
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
16 Dec 20:50:50 - [info] Starting flows
16 Dec 20:50:53 - [info] [fritzbox-callmonitor:7490] Connecting to fritzbox...
16 Dec 20:50:53 - [error] [mqtt out:Garage] missing broker configuration
16 Dec 20:50:54 - [info] Started flows
16 Dec 20:50:54 - [warn] [fritzbox-in:DSL-Link-Info] Device not ready.
16 Dec 20:50:54 - [info] [mqtt-broker:MQTT-Docker] Connected to broker: NR@mqtt://
16 Dec 20:50:54 - [info] [mqtt-broker:Loxberry] Connected to broker: mqtt://
16 Dec 20:50:54 - [info] [fritzbox-callmonitor:7490] Connected to fritzbox
16 Dec 20:50:54 - [info] [loxone-miniserver:14a36708249aedb8] Miniserver connected ( using Token-Enc
16 Dec 20:50:54 - [info] [loxone-miniserver:14a36708249aedb8] got structure file 2022-11-20 14:09:09
16 Dec 20:50:56 - [info] [filter:Finde 1] nr-regexp-filter: message dropped (not matching the '(?:1)' regular expression)
16 Dec 20:50:56 - [info] [filter:Finde 1-6] nr-regexp-filter: message dropped (not matching the '[1,\2\,3\,4\,5\,6]' regular expression)
16 Dec 20:50:56 - [info] [filter:Finde 2 (Akustisch)] nr-regexp-filter: message dropped (not matching the '(?:2)' regular expression)
16 Dec 20:51:05 - [error] [better-sonos-control:Pause] Error: HTTP response code 500 for "urn:schemas-upnp-org:service:AVTransport:1#Pause"
Error: HTTP response code 500 for "urn:schemas-upnp-org:service:AVTransport:1#Pause"
    at Request._callback (/data/node_modules/sonos/lib/sonos.js:216:23)
    at Request.self.callback (/data/node_modules/request/request.js:185:22)
    at Request.emit (node:events:527:28)
    at Request.<anonymous> (/data/node_modules/request/request.js:1154:10)
    at Request.emit (node:events:527:28)
    at IncomingMessage.<anonymous> (/data/node_modules/request/request.js:1076:12)
    at Object.onceWrapper (node:events:641:28)
    at IncomingMessage.emit (node:events:539:35)
    at endReadableNT (node:internal/streams/readable:1345:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)
16 Dec 20:51:51 - [info] [mqtt-broker:Mosquitto Synology] Connection failed to broker: mqtt://
16 Dec 20:52:09 - [info] [mqtt-broker:Mosquitto Synology] Connected to broker: mqtt://

I havent altered the flows in a long time (like weeks, or months).

My suspicion is, that since I am running watchtower, that there has been and update breaking things.

Appreciate any help!

Any proxy?

Set the log level to trace in settings.js and see if that gives any clues as to where the delay is

1 Like

That length of time quite possibly implies a TCP timeout - something waiting for a TCP/IP response and not getting it then trying again with the same result. Just a guess though. As Colin says, a trace level log should give further clues.

Everything works as expected again.
Problem was with the docker instance under which NR is running.
Thanks anyway!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.