Docker Synology

[xthephreakx]

this is no bug but a help request.

i ran the composer on my docker hosted on synology via portainer. 3 dockers are created succesfully and are up and running

but somehow i cant connect to the page am i missing something ? or do i need to do something after the dockers are created ?

[javijuji]

Ran into the same issue. Seems like the app cant reach db at port 5432. Meanwhile db seems to be running correctly on port 5432 and listening to connections.

2023-01-17 23:07:05.801 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2023-01-17 23:07:05.801 UTC [1] LOG: listening on IPv6 address "::", port 5432 2023-01-17 23:07:05.851 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2023-01-17 23:07:05.927 UTC [25] LOG: database system was shut down at 2023-01-17 23:06:41 UTC 2023-01-17 23:07:05.954 UTC [1] LOG: database system is ready to accept connections

[oae]

I am also using docker on Synology. I believe the default network created by docker on Nas cannot resolve service names. Can you create a bridge network and use that?

[xthephreakx]

Thnx for the tip I'll try that I'll keep you updated.

Update:

Added bridge network to 3 dockers. Rebooted docks and stil cannot connect.

Then removed the network created via kaizoku so that only bridge was available then Rebooted docks unfortunately same result.

[oae]

Can you try this guide?

https://drfrankenstein.co.uk/step-3-setting-up-a-docker-bridge-network/

[xthephreakx]

created the bridge via the guide. still no joy.

didnt check the logfile of the dockers i'll supply them.

kaizoku-db- PostgreSQL Database directory appears to contain a database; Skipping initialization 2023-01-18 18:38:29.507 UTC [1] LOG: starting PostgreSQL 15.1 on x86_64-pc-linux-musl, compiled by gcc (Alpine 12.2.1_git20220924-r4) 12.2.1 20220924, 64-bit 2023-01-18 18:38:29.507 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 2023-01-18 18:38:29.507 UTC [1] LOG: listening on IPv6 address "::", port 5432 2023-01-18 18:38:29.532 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432" 2023-01-18 18:38:29.566 UTC [24] LOG: database system was shut down at 2023-01-18 18:38:01 UTC 2023-01-18 18:38:29.586 UTC [1] LOG: database system is ready to accept connections 2023-01-18 18:38:34.459 UTC [34] FATAL: role "kaizoku" does not exist 2023-01-18 18:38:39.533 UTC [41] FATAL: role "kaizoku" does not exist 2023-01-18 18:38:44.621 UTC [49] FATAL: role "kaizoku" does not exist 2023-01-18 18:38:49.698 UTC [56] FATAL: role "kaizoku" does not exist

kaizoku-redis-1 1:C 18 Jan 2023 18:38:30.143 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1:C 18 Jan 2023 18:38:30.143 # Redis version=7.0.8, bits=64, commit=00000000, modified=0, pid=1, just started 1:C 18 Jan 2023 18:38:30.143 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf 1:M 18 Jan 2023 18:38:30.144 * monotonic clock: POSIX clock_gettime 1:M 18 Jan 2023 18:38:30.144 * Running mode=standalone, port=6379. 1:M 18 Jan 2023 18:38:30.145 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128. 1:M 18 Jan 2023 18:38:30.145 # Server initialized 1:M 18 Jan 2023 18:38:30.145 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. 1:M 18 Jan 2023 18:38:30.145 * Loading RDB produced by version 7.0.8 1:M 18 Jan 2023 18:38:30.145 * RDB age 28 seconds 1:M 18 Jan 2023 18:38:30.145 * RDB memory usage when created 0.82 Mb 1:M 18 Jan 2023 18:38:30.145 * Done loading RDB, keys loaded: 0, keys expired: 0. 1:M 18 Jan 2023 18:38:30.145 * DB loaded from disk: 0.000 seconds 1:M 18 Jan 2023 18:38:30.145 * Ready to accept connections

kaizoku [19:45:33.083] ERROR (4285): Invalidprisma.manga.findMany()invocation: Can't reach database server atdb:5432 Please make sure your database server is running atdb:5432. err: { "type": "PrismaClientInitializationError", "message": "\nInvalidprisma.manga.findMany()invocation:\n\n\nCan't reach database server atdb:5432\n\nPlease make sure your database server is running atdb:5432.", "stack": Error: Invalidprisma.manga.findMany()` invocation:

      Can't reach database server at `db`:`5432`

      Please make sure your database server is running at `db`:`5432`.
          at RequestHandler.handleRequestError (/app/node_modules/.pnpm/@prisma+client@4.6.1_prisma@4.6.1/node_modules/@prisma/client/runtime/index.js:34316:13)
          at RequestHandler.request (/app/node_modules/.pnpm/@prisma+client@4.6.1_prisma@4.6.1/node_modules/@prisma/client/runtime/index.js:34293:12)
          at async PrismaClient._request (/app/node_modules/.pnpm/@prisma+client@4.6.1_prisma@4.6.1/node_modules/@prisma/client/runtime/index.js:35273:16)
  "clientVersion": "4.6.1"
}

✓ set metadata.comic_info_xml to true ✓ set metadata.fetch_anilist to true ✓ set metadata.series_json to true ✓ set formats.use to cbz ✓ set downloader.download_cover to true ✓ set downloader.redownload_existing to true ✓ set downloader.chapter_name_template to [{padded-index}] {chapter} ✓ set downloader.create_manga_dir to true ✓ set downloader.create_volume_dir to false ✓ set downloader.stop_on_error to true ✓ set downloader.path to .`

[oae]

Can you share your exact docker-compose.yml file?

[xthephreakx]

sure and thnx for the fast replies !

`version: '3'

volumes: db: redis:

services: app: container_name: kaizoku image: ghcr.io/oae/kaizoku:latest environment:

• DATABASE_URL=postgresql://kaizoku:kaizoku@db:5432/kaizoku
• KAIZOKU_PORT=3000
• REDIS_HOST=redis
• REDIS_PORT=6379
• UID=1038
• GID=65547
• TZ=Europe/Amsterdam volumes:
• /volume1/docker/kaizoku/data:/data:rw
• /volume1/docker/kaizoku/config:/config:rw
• /volume1/docker/kaizoku/logs:/logs:rw depends_on: db: condition: service_healthy ports:
• '3000:3000' redis: image: redis:7-alpine volumes:
• redis:/data db: image: postgres:alpine restart: unless-stopped healthcheck: test: ['CMD-SHELL', 'pg_isready -U kaizoku'] interval: 5s timeout: 5s retries: 5 environment:
• POSTGRES_USER=kaizoku
• POSTGRES_DB=kaizoku
• POSTGRES_PASSWORD=kaizoku volumes:
• db:/var/lib/postgresql/data `

[xthephreakx]

Oke another update I noticed in the composer that there are a DB and a REDIS volume declared so I made these folders and added the locations to the composer.

Only thing that gives errors now in the logs is kaizoku docker

_ Please make sure your database server is running at db:5432. Can't reach database server at db:5432 [00:01:58.850] ERROR (5542): err: { "message": "\nInvalid prisma.manga.findMany() invocation:\n\n\nCan't reach database server at db:5432\n\nPlease make sure your database server is running at db:5432.", "type": "PrismaClientInitializationError", Error: "stack": "clientVersion": "4.6.1" Invalid prisma.manga.findMany() invocation: at RequestHandler.handleRequestError (/app/node_modules/.pnpm/@prisma+client@4.6.1_prisma@4.6.1/node_modules/@prisma/client/runtime/index.js:34316:13) at RequestHandler.request (/app/node_modules/.pnpm/@prisma+client@4.6.1_prisma@4.6.1/node_modules/@prisma/client/runtime/index.js:34293:12) at async PrismaClient._request (/app/node_modules/.pnpm/@prisma+client@4.6.1_prisma@4.6.1/node_modules/@prisma/client/runtime/index.js:35273:16)

[00:02:34.588] ERROR (5881): Please make sure your database server is running at db:5432. Can't reach database server at db:5432 Invalid prisma.manga.findMany() invocation: [00:02:46.191] ERROR (5994): _

[oae]

I tried it but I cannot reproduce this.

[xthephreakx]

Damn that's unfortunate :(. Fixed another docker which couldn't communicate with my other container which was due to I had multiple gateways enabled on my nas. But it did t fix this issue I'll try it again from scratch after I brought the kids to bed.

[xthephreakx]

Well I think fixing my gateway shizzle on the nas and redeploying the stack solved my problem :).

Thnx for the support. So I guess if anyone else has this issue on a synology nas they have to check if they have this setting set to enable cause that might brake some stuff....

[oae]

Nice.