Hi everybody,
I have been trying to setup Vikunja on my Synology for some time now but I can’t get it to work.
I followed this tutorial:
In Portainer, I can see that the API container can’t communicate with the DB.
It shows the error:
2022/10/08 02:48:01 No config file found, using default or config from environment variables.
2022-10-08T02:50:09.236049398Z: CRITICAL ▶ migration/Migrate 002 Migration failed: dial tcp X.X.X.X:3306: connect: connection timed out
usermod: no changes
I can open the Vikunja page and create an account but when I click the “create account” button, I get the error:
Request failed with status code 405
2 things I should note:
- I am not using port 443 but 5554 in my setup
- I already have a different mariadb Docker container running in my Synology. But that shouldn’t be a problem in my experience.
My docker-compose file looks like this:
version: '3'
services:
db_vikunja:
image: mariadb:10
command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
environment:
MYSQL_ROOT_PASSWORD: supersecret
MYSQL_USER: vikunja
MYSQL_PASSWORD: secret
MYSQL_DATABASE: vikunja
volumes:
- /volume1/docker/vikunja_db:/var/lib/mysql
restart: unless-stopped
api:
image: vikunja/api
environment:
VIKUNJA_DATABASE_HOST: db_vikunja
VIKUNJA_DATABASE_PASSWORD: secret
VIKUNJA_DATABASE_TYPE: mysql
VIKUNJA_DATABASE_USER: vikunja
VIKUNJA_DATABASE_DATABASE: vikunja
VIKUNJA_SERVICE_JWTSECRET: a4obw47EhNpv5p9EX4T2aJ8VX
VIKUNJA_SERVICE_FRONTENDURL: https://192.168.1.100:4321/
PUID: 1029
PGID: 100
ports:
- 3456:3456
volumes:
- /volume1/docker/vikunja:/app/vikunja/files
depends_on:
- db_vikunja
restart: unless-stopped
frontend:
image: vikunja/frontend
ports:
- 4321:80
environment:
VIKUNJA_API_URL: http://192.168.1.100:3456/api/v1
restart: unless-stopped
Any help is much appreciated!
Are there any logs from the db container?
There are logs but they don’t show anything related to the connection with the API container:
2022-10-08 02:55:32+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.9.3+maria~ubu2204 started.
2022-10-08 02:55:35+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2022-10-08 02:55:36+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:10.9.3+maria~ubu2204 started.
2022-10-08 02:55:36+00:00 [Note] [Entrypoint]: MariaDB upgrade not required
2022-10-08 2:55:36 0 [Note] mariadbd (server 10.9.3-MariaDB-1:10.9.3+maria~ubu2204) starting as process 1 ...
2022-10-08 2:55:36 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2022-10-08 2:55:36 0 [Note] InnoDB: Number of transaction pools: 1
2022-10-08 2:55:36 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions
2022-10-08 2:55:36 0 [Warning] mariadbd: io_uring_queue_init() failed with ENOSYS: check seccomp filters, and the kernel version (newer than 5.1 required)
2022-10-08 2:55:36 0 [Warning] InnoDB: liburing disabled: falling back to innodb_use_native_aio=OFF
2022-10-08 2:55:36 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB
2022-10-08 2:55:36 0 [Note] InnoDB: Completed initialization of buffer pool
2022-10-08 2:55:36 0 [Note] InnoDB: Buffered log writes (block size=512 bytes)
2022-10-08 2:55:36 0 [Note] InnoDB: 128 rollback segments are active.
2022-10-08 2:55:36 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ...
2022-10-08 2:55:36 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB.
2022-10-08 2:55:36 0 [Note] InnoDB: log sequence number 55759; transaction id 41
2022-10-08 2:55:36 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2022-10-08 2:55:36 0 [Note] Plugin 'FEEDBACK' is disabled.
2022-10-08 2:55:36 0 [Warning] You need to use --log-bin to make --expire-logs-days or --binlog-expire-logs-seconds work.
2022-10-08 2:55:36 0 [Note] Server socket created on IP: '0.0.0.0'.
2022-10-08 2:55:36 0 [Note] Server socket created on IP: '::'.
2022-10-08 2:55:36 0 [Note] InnoDB: Buffer pool(s) load completed at 221008 2:55:36
2022-10-08 2:55:36 0 [Note] mariadbd: ready for connections.
Version: '10.9.3-MariaDB-1:10.9.3+maria~ubu2204' socket: '/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution
Does it work if you give it some time? Sometimes the mariadb container ist not ready right away.
I have kept it running for ~3 days but nothing changed.
Can you open a shell into the api container and see if you can reach the db container from there?
It seems that it can’t communicate with the db container.
I did docker exec -it [Docker container id of api container] sh and then tried ping [container id of db]. But it timed out.
I also defined a network for those 3 containers but it didn’t change anything.
Did you put them all in the same network? Usually docker compose will do that automatically if you don’t specify any networks yourself.
Yes, they are all in the same network.
Can you docker inspect the DB container to check if the hostname was set correctly?
I noticed that the container didn’t have the name vikunja_db as I specified in the docker-compose file but actually vikunja-vikunja_db-1.
I set vikunja-vikunja_db-1 as VIKUNJA_DATABASE_HOST in the vikunja-api container but it didn’t change anything.
I could see that even with vikunja_db as VIKUNJA_DATABASE_HOST, the container knew that the database was at the correct internal IP address
I was able to use your docker-compose setup as posted in your first comment without issues. Can you check how it behaves on a separate host? This does not look like a Vikunja-specific issue.
wow, okay, that is weird. Thank you for checking. I will see if I need to change anything in the Synology setup.
Okay, I give up.
I tried to create the containers via SSH and docker-compose instead of Portainer. I tried it with different docker networks and by adding link in the docker-compose file. I know that the containers are in the same Docker network but the api container can’t ping the db container (or frontend for that matter)
I have the feeling that the problem is the other mariaDB container already running in my environment. I can’t see why this would be a problem and I also changed the port to 3307 but it still didn’t work.
The other container probably has another name?
Even if, wouldn’t that only error out on the credentials and not right on ping?
Yes, it has a different name. And yeah, that’s why this is so frustrating. I don’t understand why the ping is not working at all.