[BUG] - Stuck Scanning Connections

[ondrovic]

Describe the bug Brand new docker compose instance, with mysql running in same stack

To Reproduce Steps to reproduce the behavior:

1. Using the following

docker-compose.yml

``` services: db: image: mysql:latest restart: always env_file: "./.env" ports: - "${MYSQL_PORT}:${MYSQL_PORT}" volumes: - ./mysql_data:/var/lib/mysql webdb: image: webdb/app:latest restart: always ports: - "127.0.0.1:22071:22071" volumes: - ./.webdb:/usr/src/app/static/version depends_on: - db volumes: mysql_data: webdb: ```

.env

``` MYSQL_ROOT_PASSWORD= MYSQL_DATABASE="db_name" MYSQL_USER=user MYSQL_PASSWORD= MYSQL_PORT=3306 ```

2. Run

 docker compose up -d

3. Once container is up and running

   • Navigate to

     • Webdb
4. Observer the infinite loop on Scanning Connections

Expected behavior Should list the found connections and allow you to connect to them

Screenshots

Images


Additional context

Console errors

``` Error: Uncaught (in promise): W: {"headers":{"normalizedNames":{},"lazyUpdate":null,"headers":{}},"status":0,"statusText":"Unknown Error","url":"/api/server/connect","ok":false,"name":"HttpErrorResponse","message":"Http failure response for /api/server/connect: 0 Unknown Error","error":{"isTrusted":true}} ``` ``` Failed to load resource: net::ERR_EMPTY_RESPONSE :22071/api/connect:1 ```

Scan API Results

```json [ { "wrapper": "MongoDB", "host": "host.docker.internal", "port": 27015 }, { "wrapper": "MySQL", "host": "host.docker.internal", "port": 3306 } ] ```

Connect API Results

```json { "wrapper": "MongoDB", "host": "host.docker.internal", "port": 27015, "name": "undefined@host.docker.internal:27015", "scanned": true, "driver": {}, "params": { "serverSelectionTimeoutMS": 2000, "authSource": "admin" }, "dbs": [], "relations": [], "indexes": [], "complexes": {}, "isLoading": false } ``` ```json { "wrapper": "MySQL", "host": "host.docker.internal", "port": 3306, "name": "undefined@host.docker.internal:3306", "scanned": true, "driver": {}, "params": { "dateStrings": true, "multipleStatements": true, "supportBigNumbers": true, "bigNumberStrings": true }, "dbs": [], "relations": [], "indexes": [], "complexes": {}, "isLoading": false } ```

[WebDB-App]

I just try with your exact config and maybe it could comes from mysql

When I up the compose then update the mysql image and restart the services, mysql crash and loop rebooting

Can you check if the mysql container is well running

If so can you try try manually connect to it docker exec $(docker ps -q --filter ancestor=mysql) mysql -u user --password="<changeme>" -e "show databases;"

[ondrovic]

from the above

mysql: [Warning] Using a password on the command line interface can be insecure.
Database
information_schema
nexus_mod_tracker
performance_schema

[WebDB-App]

Can you give me the backend log please

docker logs $(docker ps -a -q --filter ancestor=webdb/app )

[ondrovic]

<--- Last few GCs --->

[1:0x7f1268eb0000]    34166 ms: Mark-Compact 4047.7 (4128.7) -> 4047.7 (4128.7) MB, pooled: 0 MB, 2326.90 / 0.00 ms  (average mu = 0.199, current mu = 0.067) allocation failure; scavenge might not succeed
[1:0x7f1268eb0000]    35688 ms: Mark-Compact 4063.4 (4128.7) -> 4063.4 (4160.7) MB, pooled: 0 MB, 1512.90 / 0.00 ms  (average mu = 0.116, current mu = 0.006) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

[aleluff]

Do you have free RAM ?

If yes, can you try adding more memory to your docker process and retry please

[ondrovic]

I adjust like this Even tried upping the swap

but am still getting this

22071             database WebDB App running

<--- Last few GCs --->

[1:0x7f5f516e9000]    10672 ms: Scavenge (reduce) (interleaved) 2046.1 (2084.2) -> 2046.1 (2081.2) MB, pooled: 0 MB, 5.72 / 0.00 ms  (average mu = 0.425, current mu = 0.238) allocation failure;
[1:0x7f5f516e9000]    11111 ms: Mark-Compact (reduce) 2047.1 (2081.2) -> 2047.1 (2082.2) MB, pooled: 0 MB, 432.96 / 0.00 ms  (+ 7.6 ms in 0 steps since start of marking, biggest step 0.0 ms, walltime since start of marking 455 ms) (average mu = 0.294, cur

<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----

22071             database WebDB App running

[abiche-u]

Can you give the result of docker stats --no-stream

[ondrovic]

CONTAINER ID   NAME                        CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O   PIDS
4c76cace7a8b   nexus-mod-tracker-webdb-1   0.00%     22.3MiB / 31.29GiB    0.07%     1.23kB / 0B       0B / 0B     11
59b53804243a   nexus-mod-tracker-db-1      0.30%     460.8MiB / 31.29GiB   1.44%     746B / 0B         0B / 0B     50

it does seem to spike when trying to load the page, but usually only cpu mem seems fine

CONTAINER ID   NAME                        CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O   PIDS
4c76cace7a8b   nexus-mod-tracker-webdb-1   294.75%   3.904GiB / 31.29GiB   12.47%    45kB / 29.5kB     0B / 0B     11
59b53804243a   nexus-mod-tracker-db-1      0.47%     460.8MiB / 31.29GiB   1.44%     2.92kB / 1.88kB   0B / 0B     50

[abiche-u]

Can you modify the compose file following :

webdb:
        image: webdb/app
        restart: always
        environment:
            WATCHER_EXCLUDE: true
        volumes:
            - "$HOME/.webdb:/usr/src/app/static/version"
        ports:
            - "127.0.0.1:22071:22071"

Then docker-compose down webdb && docker-compose up -d webdb

[ondrovic]

all the way through nothing running to just after the it errored out in console

 webdb:
    image: webdb/app:latest
    restart: always
    environment:
      WATCHER_EXCLUDE: true
    volumes:
      - "$HOME/.webdb:/usr/src/app/static/version"
    ports:
      - "127.0.0.1:22071:22071"

[abiche-u]

Can you give the curl API call which cause crash please

[ondrovic]

these are the two connects which seem to fail

curl 'http://localhost:22071/api/server/connect' \
  -H 'Accept: application/json, text/plain, */*' \
  -H 'Accept-Language: en-US,en;q=0.9' \
  -H 'Connection: keep-alive' \
  -H 'Content-Type: application/json' \
  -H $'Cookie: barspot_pageBarTop=-1; barspot_pageBarTop2=-1; barspot_pageBarMidPx=400; barspot_imageEditorSizeBar=-1; selected_model=OfficialStableDiffusion%2Fsd_xl_base_1.0%2C1024%2C1024%2Cstable-diffusion-xl-v1-base%2Cstable-diffusion-xl-v1; ab.storage.deviceId.240e177d-4779-41c2-b484-3af37ffa8685=%7B%22g%22%3A%22a1926f81-1a34-ef56-d0be-6ed618e0c3a4%22%2C%22c%22%3A1720565768896%2C%22l%22%3A1720565768896%7D; pma_lang=en; pmaUser-1=7we8Jyz%2Fmmoarb%2F5y6re89wzm2nMeTNDKEOi%2BircxUnWSrsRM%2B%2BhKKRxyxs%3D; pga4_session=aa1b20ef-20fc-478d-9999-ce8e1e384e93\u0021eRC55pS7Tao2qeWAjSSzGAd72tTz9pxuEzZWV2/uBjs=' \
  -H 'Origin: http://localhost:22071' \
  -H 'Referer: http://localhost:22071/' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36' \
  -H 'sec-ch-ua: "Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Windows"' \
  --data-raw '{"wrapper":"MongoDB","host":"host.docker.internal","port":27015,"name":"undefined@host.docker.internal:27015","scanned":true,"driver":{},"params":{"serverSelectionTimeoutMS":2000,"authSource":"admin"},"dbs":[],"relations":[],"indexes":[],"complexes":{},"isLoading":false}'

  curl 'http://localhost:22071/api/server/connect' \
  -H 'Accept: application/json, text/plain, */*' \
  -H 'Accept-Language: en-US,en;q=0.9' \
  -H 'Connection: keep-alive' \
  -H 'Content-Type: application/json' \
  -H $'Cookie: barspot_pageBarTop=-1; barspot_pageBarTop2=-1; barspot_pageBarMidPx=400; barspot_imageEditorSizeBar=-1; selected_model=OfficialStableDiffusion%2Fsd_xl_base_1.0%2C1024%2C1024%2Cstable-diffusion-xl-v1-base%2Cstable-diffusion-xl-v1; ab.storage.deviceId.240e177d-4779-41c2-b484-3af37ffa8685=%7B%22g%22%3A%22a1926f81-1a34-ef56-d0be-6ed618e0c3a4%22%2C%22c%22%3A1720565768896%2C%22l%22%3A1720565768896%7D; pma_lang=en; pmaUser-1=7we8Jyz%2Fmmoarb%2F5y6re89wzm2nMeTNDKEOi%2BircxUnWSrsRM%2B%2BhKKRxyxs%3D; pga4_session=aa1b20ef-20fc-478d-9999-ce8e1e384e93\u0021eRC55pS7Tao2qeWAjSSzGAd72tTz9pxuEzZWV2/uBjs=' \
  -H 'Origin: http://localhost:22071' \
  -H 'Referer: http://localhost:22071/' \
  -H 'Sec-Fetch-Dest: empty' \
  -H 'Sec-Fetch-Mode: cors' \
  -H 'Sec-Fetch-Site: same-origin' \
  -H 'User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36' \
  -H 'sec-ch-ua: "Chromium";v="128", "Not;A=Brand";v="24", "Google Chrome";v="128"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "Windows"' \
  --data-raw '{"wrapper":"MySQL","host":"host.docker.internal","port":3306,"name":"undefined@host.docker.internal:3306","scanned":true,"driver":{},"params":{"dateStrings":true,"multipleStatements":true,"supportBigNumbers":true,"bigNumberStrings":true},"dbs":[],"relations":[],"indexes":[],"complexes":{},"isLoading":false}'

[abiche-u]

Does they respond with an JSON or do they make the backend crash

Can you screenshot the chrome network tab please

[ondrovic]

So this is the scan which works

filtered connect errors Both connects have no respone Console log showing the crash as provided before

[aleluff]

Can you retry when mongodb is down please

[ondrovic]

not sure I follow, this is a brand new instance following the docs so what was in my docker-compose that I posted was all there was. I don't define a mongodb, nor did I have one running. It was literally just

* WebDB
* MySql

Running in a docker container

[abiche-u]

WebDB found something listening on port 27015. It considered that as a possible MongoDB instance I just found out that Steam often use this port

To be completly sure about, can you close Steam and retry please

[ondrovic]

So fun fact port 27015 is this

I shut it down and it worked, guess that's why auto scanning is sometimes a bad idea, at very least it should gracefully handle the time out when something like this happens

At least it exposed a potential edge case ;-)

I did try doing to only scan the db but it still failed as soon as that service was back on

services:
  db:
    image: mysql:latest
    restart: always
    env_file: "./.env"
    ports:
      - "${MYSQL_PORT}:${MYSQL_PORT}"
    volumes:
      - ./mysql_data:/var/lib/mysql
      - ./schema.sql:/docker-entrypoint-initdb.d/schema.sql

  webdb:
    image: webdb/app:latest
    restart: always
    environment:
      SCAN_HOSTS: db
    volumes:
      - "./.webdb:/usr/src/app/static/version"
    ports:
      - "127.0.0.1:22071:22071"
    depends_on:
      - db

volumes:
  mysql_data:
  webdb:

[WebDB-App]

Autoscanning is always a good idea =)

Thanks for your patience and cooperation btw

It will be fix in 30 minutes

[ondrovic]

Glad to help prevent others from running into the same issue, ill test once it's updated and report back

[aleluff]

It's deployed if you want

[ondrovic]

Verified working

[aleluff]

i hope you will enjoy the tool, It would be a pleasure to have feedback if it's not too much please

[ondrovic]

sure I will play around with it when next time I work on a database and let you know 😉