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

[GH-ISSUE #2020] Unable to set log file location properly due to logging.go path handling #6525

New Issue
Closed
opened 2026-04-20 17:07:30 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-20 17:07:30 -05:00
Owner
Copy Link

Originally created by @tomaskir on GitHub (Dec 22, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2020

Description

Greetings.

Running Vikunja in Docker, using the vikunja/vikunja:1.0.0-rc3 image. It appears that the path for the file based logging can not be setup properly.

According to documentation, log.path (eq. VIKUNJA_LOG_PATH) is supposed to be <rootpath>logs.
Since the Docker image sets ENV VIKUNJA_SERVICE_ROOTPATH=/app/vikunja/, logs should be in /app/vikunja/logs.

However, setting VIKUNJA_LOG_STANDARD=file, and properly setting in docker-compose:

...
   environment:
      - VIKUNJA_LOG_STANDARD=file
...
    volumes:
      - ./vikunja-data:/app/vikunja/files
      - ./vikunja-logs:/app/vikunja/logs
...

And making sure the user (uid 1000) has access to the directory:

drwxr-s--- 3 1000 1000 4096 dec 22 23:16 vikunja-data
drwxr-s--- 2 1000 1000 4096 dec 22 23:15 vikunja-logs

I receive this error on startup:

time=2025-12-22T23:04:22.493+01:00 level=ERROR msg="Could not create logfile ./standard.log: open ./standard.log: permission denied"

It looks like the log path is being ignored and the file is being created in service.rootpath instead of the log.path.

Looking at pkg/log/logging.go, it seems the log.path is set only AFTER the makeLogHandler is called, and therefore it's set at . at handle creation:

b0114b71e7/pkg/log/logging.go (L32)

b0114b71e7/pkg/log/logging.go (L89-L93)

b0114b71e7/pkg/log/logging.go (L110)

This would be consistent with what I'm seeing in the logs.

Vikunja Version

1.0.0-rc3

Browser and version

No response

Can you reproduce the bug on the Vikunja demo site?

No

Screenshots

No response

Originally created by @tomaskir on GitHub (Dec 22, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/2020 ### Description Greetings. Running Vikunja in Docker, using the `vikunja/vikunja:1.0.0-rc3` image. It appears that the path for the `file` based logging can not be setup properly. According to documentation, `log.path` (eq. `VIKUNJA_LOG_PATH`) is supposed to be `<rootpath>logs`. Since the Docker image sets `ENV VIKUNJA_SERVICE_ROOTPATH=/app/vikunja/`, logs should be in `/app/vikunja/logs`. However, setting `VIKUNJA_LOG_STANDARD=file`, and properly setting in `docker-compose`: ``` ... environment: - VIKUNJA_LOG_STANDARD=file ... volumes: - ./vikunja-data:/app/vikunja/files - ./vikunja-logs:/app/vikunja/logs ... ``` And making sure the user (uid `1000`) has access to the directory: ``` drwxr-s--- 3 1000 1000 4096 dec 22 23:16 vikunja-data drwxr-s--- 2 1000 1000 4096 dec 22 23:15 vikunja-logs ``` I receive this error on startup: ``` time=2025-12-22T23:04:22.493+01:00 level=ERROR msg="Could not create logfile ./standard.log: open ./standard.log: permission denied" ``` It looks like the log path is being ignored and the file is being created in `service.rootpath` instead of the `log.path`. Looking at [pkg/log/logging.go](https://github.com/go-vikunja/vikunja/blob/main/pkg/log/logging.go), it seems the `log.path` is set only AFTER the `makeLogHandler` is called, and therefore it's set at `.` at handle creation: https://github.com/go-vikunja/vikunja/blob/b0114b71e75182a9877eb31dd4a61d00b97a40fe/pkg/log/logging.go#L32 https://github.com/go-vikunja/vikunja/blob/b0114b71e75182a9877eb31dd4a61d00b97a40fe/pkg/log/logging.go#L89-L93 https://github.com/go-vikunja/vikunja/blob/b0114b71e75182a9877eb31dd4a61d00b97a40fe/pkg/log/logging.go#L110 This would be consistent with what I'm seeing in the logs. ### Vikunja Version 1.0.0-rc3 ### Browser and version _No response_ ### Can you reproduce the bug on the Vikunja demo site? No ### Screenshots _No response_
GiteaMirror added the area/api label 2026-04-20 17:07:30 -05:00
GiteaMirror commented 2026-04-20 17:07:32 -05:00
Author
Owner
Copy Link

@vikunja-bot-app[bot] commented on GitHub (Jan 8, 2026):

This issue has been fixed in #2064, please check with the next unstable build (should be ready for deployment in ~30min, also on the demo).

<!-- gh-comment-id:3723984260 --> @vikunja-bot-app[bot] commented on GitHub (Jan 8, 2026): This issue has been fixed in #2064, please check with the next unstable build (should be ready for deployment in ~30min, also on [the demo](https://try.vikunja.io)).
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 area/api
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#6525
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?