github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 19:47:47 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

No config file found, using default or config from environment variables. #2076

New Issue
Closed
opened 2026-03-22 13:54:57 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-03-22 13:54:57 -05:00
Owner
Copy Link

Originally created by @biggt on GitHub (Feb 6, 2025).

Eventually, over time, the Vikunja app crashes and the status shows that it's going to restart but never does.

I don't know how to duplicate this issue, other than just waiting... it's now done this two or three days in a row now...


2025-02-06T18:49:11Z: WEB       ▶ 10.0.3.250  GET 200 /api/v1/notifications?page=1 2.714438ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
2025-02-06T18:50:12Z: WEB       ▶ 10.0.3.250  GET 200 /api/v1/notifications?page=1 3.117954ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0
2025-02-06T18:52:24Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:24Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:25Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:25Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:27Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:27Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:29Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:29Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:31Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:31Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:34Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:34Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:38Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:38Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:46Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:46Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:52:59Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:52:59Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:53:25Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:53:26Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:54:17Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:54:17Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:55:18Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:55:18Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:56:18Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:56:18Z: CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving
2025-02-06T18:57:19Z: INFO      ▶ 001 No config file found, using default or config from environment variables.
2025-02-06T18:57:24Z: CRITICAL  ▶ 002 dial tcp: lookup redis: i/o timeout

Now, I don't specify my config file as a file, but instead specify environment variables inside the docker container. This appears to be working just fine... until randomly it crashes (maybe due to inactivity?)

services:
  vikunja:
    image: vikunja/vikunja
    container_name: vikunja_app
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://vikunja.domain.com
      VIKUNJA_DATABASE_HOST: db
      VIKUNJA_DATABASE_PASSWORD: redacted
      VIKUNJA_DATABASE_TYPE: mysql
      VIKUNJA_DATABASE_USER: vikunja
      VIKUNJA_DATABASE_DATABASE: vikunja
      VIKUNJA_SERVICE_JWTSECRET: redacted
      VIKUNJA_REDIS_ENABLED: 1
      VIKUNJA_REDIS_HOST: 'redis:6379'
      VIKUNJA_CACHE_ENABLED: 1
      VIKUNJA_CACHE_TYPE: redis
      VIKUNJA_SERVICE_ENABLEREGISTRATION: false
      VIKUNJA_SERVICE_ENABLEEMAILREMINDERS: true
      VIKUNJA_MAILER_ENABLED: true
      VIKUNJA_MAILER_HOST: mail.redacted.com
      VIKUNJA_MAILER_PORT: 587
      VIKUNJA_MAILER_AUTHTYPE: login
      VIKUNJA_MAILER_USERNAME: admin@redacted.com
      VIKUNJA_MAILER_PASSWORD: redacted
      VIKUNJA_MAILER_FROMEMAIL: vikunja@redacted.com
    ports:
      - 3456:3456
    volumes:
      - ./files:/app/vikunja/files
#      - ./config/config.yml:/etc/vikunja/config.yml
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: mariadb:10
    container_name: vikunja_db
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
    environment:
      MYSQL_ROOT_PASSWORD: redacted
      MYSQL_USER: vikunja
      MYSQL_PASSWORD: redacted
      MYSQL_DATABASE: vikunja
    volumes:
      - ./db:/var/lib/mysql
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h localhost -u $$MYSQL_USER --password=$$MYSQL_PASSWORD"]
      interval: 2s
      start_period: 30s

  redis:
    container_name: vikunja_redis
    image: redis
Originally created by @biggt on GitHub (Feb 6, 2025). Eventually, over time, the Vikunja app crashes and the status shows that it's going to restart but never does. I don't know how to duplicate this issue, other than just waiting... it's now done this two or three days in a row now... ``` 2025-02-06T18:49:11Z: WEB ▶ 10.0.3.250 GET 200 /api/v1/notifications?page=1 2.714438ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0 2025-02-06T18:50:12Z: WEB ▶ 10.0.3.250 GET 200 /api/v1/notifications?page=1 3.117954ms - Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0 2025-02-06T18:52:24Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:24Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:25Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:25Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:27Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:27Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:29Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:29Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:31Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:31Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:34Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:34Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:38Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:38Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:46Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:46Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:52:59Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:52:59Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:53:25Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:53:26Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:54:17Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:54:17Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:55:18Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:55:18Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:56:18Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:56:18Z: CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving 2025-02-06T18:57:19Z: INFO ▶ 001 No config file found, using default or config from environment variables. 2025-02-06T18:57:24Z: CRITICAL ▶ 002 dial tcp: lookup redis: i/o timeout ``` Now, I don't specify my config file as a file, but instead specify environment variables inside the docker container. This appears to be working just fine... until randomly it crashes (maybe due to inactivity?) ``` services: vikunja: image: vikunja/vikunja container_name: vikunja_app environment: VIKUNJA_SERVICE_PUBLICURL: https://vikunja.domain.com VIKUNJA_DATABASE_HOST: db VIKUNJA_DATABASE_PASSWORD: redacted VIKUNJA_DATABASE_TYPE: mysql VIKUNJA_DATABASE_USER: vikunja VIKUNJA_DATABASE_DATABASE: vikunja VIKUNJA_SERVICE_JWTSECRET: redacted VIKUNJA_REDIS_ENABLED: 1 VIKUNJA_REDIS_HOST: 'redis:6379' VIKUNJA_CACHE_ENABLED: 1 VIKUNJA_CACHE_TYPE: redis VIKUNJA_SERVICE_ENABLEREGISTRATION: false VIKUNJA_SERVICE_ENABLEEMAILREMINDERS: true VIKUNJA_MAILER_ENABLED: true VIKUNJA_MAILER_HOST: mail.redacted.com VIKUNJA_MAILER_PORT: 587 VIKUNJA_MAILER_AUTHTYPE: login VIKUNJA_MAILER_USERNAME: admin@redacted.com VIKUNJA_MAILER_PASSWORD: redacted VIKUNJA_MAILER_FROMEMAIL: vikunja@redacted.com ports: - 3456:3456 volumes: - ./files:/app/vikunja/files # - ./config/config.yml:/etc/vikunja/config.yml depends_on: db: condition: service_healthy restart: unless-stopped db: image: mariadb:10 container_name: vikunja_db command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci environment: MYSQL_ROOT_PASSWORD: redacted MYSQL_USER: vikunja MYSQL_PASSWORD: redacted MYSQL_DATABASE: vikunja volumes: - ./db:/var/lib/mysql restart: unless-stopped healthcheck: test: ["CMD-SHELL", "mysqladmin ping -h localhost -u $$MYSQL_USER --password=$$MYSQL_PASSWORD"] interval: 2s start_period: 30s redis: container_name: vikunja_redis image: redis ```
GiteaMirror commented 2026-03-22 13:54:58 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 7, 2025):

This line:

CRITICAL  ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving

seems to indicate a problem with your redis server. What's in the logs of it?

@kolaente commented on GitHub (Feb 7, 2025): This line: ``` CRITICAL ▶ 002 dial tcp: lookup redis on 127.0.0.11:53: server misbehaving ``` seems to indicate a problem with your redis server. What's in the logs of it?
GiteaMirror commented 2026-03-22 13:54:58 -05:00
Author
Owner
Copy Link

@biggt commented on GitHub (Feb 11, 2025):

Yes, the issue does appear to be specifically with the Redis container crashing or dying. Here are the logs for the Redis container:

administrator@prd-docker13:/dockerLocal/remmina$ sudo docker logs -f  vikunja_redis
1:C 06 Feb 2025 20:26:36.736 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it 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:C 06 Feb 2025 20:26:36.736 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1:C 06 Feb 2025 20:26:36.736 * Redis version=7.4.2, bits=64, commit=00000000, modified=0, pid=1, just started
1:C 06 Feb 2025 20:26:36.736 # 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 06 Feb 2025 20:26:36.737 * monotonic clock: POSIX clock_gettime
1:M 06 Feb 2025 20:26:36.739 * Running mode=standalone, port=6379.
1:M 06 Feb 2025 20:26:36.740 * Server initialized
1:M 06 Feb 2025 20:26:36.740 * Ready to accept connections tcp
1:signal-handler (1738989042) Received SIGTERM scheduling shutdown...
1:M 08 Feb 2025 04:30:43.005 * User requested shutdown...
1:M 08 Feb 2025 04:30:43.005 * Saving the final RDB snapshot before exiting.
1:M 08 Feb 2025 04:30:43.020 * DB saved on disk
1:M 08 Feb 2025 04:30:43.020 # Redis is now ready to exit, bye bye...

However, I know that since Redis is being moved away from by so many since it's no longer open source for future versions, I instead switched to Valkey as a direct replacement. It's configured the same way Redis was and is working fine with no instability to speak of.

Original redis config:

 redis:
    container_name: vikunja_redis
    image: redis
    restart: on-failure

New valkey config:

  memory-caching:
    image: valkey/valkey:8.0.2
    container_name: vikunja_valkey
    restart: always

Additionally, in the Vikunja app container section:
Updated from

     VIKUNJA_REDIS_ENABLED: 1
      VIKUNJA_REDIS_HOST: 'redis:6379'
      VIKUNJA_CACHE_ENABLED: 1
      VIKUNJA_CACHE_TYPE: redis

to

      VIKUNJA_REDIS_ENABLED: 1
      VIKUNJA_REDIS_HOST: 'memory-caching:6379'
      VIKUNJA_CACHE_ENABLED: 1
      VIKUNJA_CACHE_TYPE: redis

This is fully operational for me and I'm not having any of the previous crashes.

@biggt commented on GitHub (Feb 11, 2025): Yes, the issue does appear to be specifically with the Redis container crashing or dying. Here are the logs for the Redis container: ``` administrator@prd-docker13:/dockerLocal/remmina$ sudo docker logs -f vikunja_redis 1:C 06 Feb 2025 20:26:36.736 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it 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:C 06 Feb 2025 20:26:36.736 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 1:C 06 Feb 2025 20:26:36.736 * Redis version=7.4.2, bits=64, commit=00000000, modified=0, pid=1, just started 1:C 06 Feb 2025 20:26:36.736 # 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 06 Feb 2025 20:26:36.737 * monotonic clock: POSIX clock_gettime 1:M 06 Feb 2025 20:26:36.739 * Running mode=standalone, port=6379. 1:M 06 Feb 2025 20:26:36.740 * Server initialized 1:M 06 Feb 2025 20:26:36.740 * Ready to accept connections tcp 1:signal-handler (1738989042) Received SIGTERM scheduling shutdown... 1:M 08 Feb 2025 04:30:43.005 * User requested shutdown... 1:M 08 Feb 2025 04:30:43.005 * Saving the final RDB snapshot before exiting. 1:M 08 Feb 2025 04:30:43.020 * DB saved on disk 1:M 08 Feb 2025 04:30:43.020 # Redis is now ready to exit, bye bye... ``` However, I know that since Redis is being moved away from by so many since it's no longer open source for future versions, I instead switched to Valkey as a direct replacement. It's configured the same way Redis was and is working fine with no instability to speak of. Original redis config: ``` redis: container_name: vikunja_redis image: redis restart: on-failure ``` New valkey config: ``` memory-caching: image: valkey/valkey:8.0.2 container_name: vikunja_valkey restart: always ``` Additionally, in the Vikunja app container section: Updated from ``` VIKUNJA_REDIS_ENABLED: 1 VIKUNJA_REDIS_HOST: 'redis:6379' VIKUNJA_CACHE_ENABLED: 1 VIKUNJA_CACHE_TYPE: redis ``` to ``` VIKUNJA_REDIS_ENABLED: 1 VIKUNJA_REDIS_HOST: 'memory-caching:6379' VIKUNJA_CACHE_ENABLED: 1 VIKUNJA_CACHE_TYPE: redis ``` This is fully operational for me and I'm not having any of the previous crashes.
GiteaMirror commented 2026-03-22 13:54:59 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Feb 11, 2025):

Looks like you found a workaround, closing this now.

@kolaente commented on GitHub (Feb 11, 2025): Looks like you found a workaround, closing this now.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#2076
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?