github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-10 22:06:34 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

When LFS/packages are disabled, gitea dump exits with error and gitea doctor --all logs errors #10473

New Issue
Closed
opened 2025-11-02 09:08:22 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-02 09:08:22 -06:00
Owner
Copy Link

Originally created by @gavinbeatty on GitHub (Mar 22, 2023).

Originally assigned to: @Zettat123 on GitHub.

Description

My /etc/gitea/app.ini contains the following to disable LFS and packages:

[server]
LFS_START_SERVER = false
[packages]
ENABLED = false

gitea dump

When running the following dump command (from within a systemd unit running as the same user as the gitea process, everything is set up properly on that end), the dump appears to successfully create a backup archive, but the process logs errors and more importantly, exits non-zero.

/usr/bin/env GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea dump -c /etc/gitea/app.ini --type tar.xz --file /var/lib/gitea/backup/gitea/$(date -Iseconds)-gitea-dump

Here is the log taken from journalctl output:

systemd[1]: Starting Gitea Backup...
gitea-backup[3784944]: 2023/03/21 23:58:38 ...es/setting/server.go:328:loadServerFrom() [I] The provided APP_DATA_PATH: data is not absolute - it will be made absolute against the work path: /var/lib/gitea
gitea-backup[3784944]: 2023/03/21 23:58:38 ...dules/setting/log.go:331:initLogFrom() [I] Gitea Log Mode: Console(Console:info)
gitea-backup[3784944]: 2023/03/21 23:58:38 ...dules/setting/log.go:286:generateNamedLogger() [I] Router Log: Console(console:info)
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/setting/cache.go:75:loadCacheFrom() [I] Cache Service Enabled
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/setting/cache.go:90:loadCacheFrom() [I] Last Commit Cache Service Enabled
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/setting/session.go:74:loadSessionFrom() [I] Session Service Enabled
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:175:initAttachments() [I] Initialising Attachment storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/attachments
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/avatars
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:191:initRepoAvatars() [I] Initialising Repository Avatar storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/repo-avatars
gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:197:initRepoArchives() [I] Initialising Repository Archive storage with type: local
gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/repo-archive
gitea-backup[3784944]: 2023/03/21 23:58:38 cmd/dump.go:246:runDump() [I] Dumping local repositories... /var/lib/gitea/repos
gitea-backup[3784944]: Failed to dump LFS objects: LFS isn't enabled
gitea-backup[3784944]: 2023/03/22 00:08:15 cmd/dump.go:162:fatal() [F] Failed to dump LFS objects: LFS isn't enabled
systemd[1]: gitea-backup.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: gitea-backup.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Gitea Backup.
systemd[1]: gitea-backup.service: Consumed 9min 23.556s CPU time.

A workaround I am using now is to add --skip-lfs-data --skip-package-data to the dump command.

gitea doctor

A similar but not identical issue exists for the following gitea doctor command, where it logs errors but does exit zero:

/usr/bin/env GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea doctor -c /etc/gitea/app.ini -w /var/lib/gitea -C /var/lib/gitea/custom --all

Log output:

systemd[1]: Starting Gitea Doctor: logs about whether there are config/db issues, etc....
gitea-doctor[3785590]: [1] Garbage collect LFS
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [2] Check paths and basic configuration
gitea-doctor[3785590]:  - [I] Configuration File Path:    "/etc/gitea/app.ini"
gitea-doctor[3785590]:  - [I] Repository Root Path:       "/var/lib/gitea/repos"
gitea-doctor[3785590]:  - [I] Data Root Path:             "/var/lib/gitea/data"
gitea-doctor[3785590]:  - [I] Custom File Root Path:      "/var/lib/gitea/custom"
gitea-doctor[3785590]:  - [I] Work directory:             "/var/lib/gitea"
gitea-doctor[3785590]:  - [I] Log Root Path:              "/var/log/gitea/"
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [3] Check if there are orphaned archives in storage
gitea-doctor[3785590]:  - [I] Found 0 (0 B) repo archive(s)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [4] Check if there are orphaned attachments in storage
gitea-doctor[3785590]:  - [I] Found 0 (0 B) attachment(s)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [5] Check if there are orphaned avatars in storage
gitea-doctor[3785590]:  - [I] Found 1 (642 B) avatar(s)
gitea-doctor[3785590]:  - [I] Found 0 (0 B) repo avatar(s)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [6] Check if there are orphaned lfs files in storage
gitea-doctor[3785590]:  - [E] Error whilst iterating LFS file storage: LFS isn't enabled
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [7] Check if there are orphaned package blobs in storage
gitea-doctor[3785590]:  - [E] Error whilst iterating package blob storage: Packages isn't enabled
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [8] Check if there are orphaned storage files
gitea-doctor[3785590]:  - [I] Found 0 (0 B) attachment(s)
gitea-doctor[3785590]:  - [E] Error whilst iterating LFS file storage: LFS isn't enabled
gitea-doctor[3785590]: ERROR
gitea-doctor[3785590]: [9] Check Database Version
gitea-doctor[3785590]:  - [I] Expected database version: 244
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [10] Check consistency of database
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [11] Check if user with wrong type exist
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [12] Check if OpenSSH authorized_keys file is up-to-date
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [13] Check if SCRIPT_TYPE is available
gitea-doctor[3785590]:  - [I] ScriptType bash is on the current PATH at /usr/bin/bash
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [14] Check if hook files are up-to-date and executable
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [15] Recalculate Stars number for all user
gitea-doctor[3785590]:  - [I] No check available for User Stars numbers (skipped)
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [16] Check old archives
gitea-doctor[3785590]:  - [I] 0 old archives in repository need to be deleted
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [17] Check that all git repositories have receive.advertisePushOptions set to true
gitea-doctor[3785590]:  - [I] Checked 17 repositories, 0 need updates.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [18] Check for incorrectly dumped repo_units (See #16961)
gitea-doctor[3785590]:  - [I] Found no broken repo_units
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [19] Recalculate merge bases
gitea-doctor[3785590]:  - [I] All 0 PRs in 17 repos have a correct mergebase
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [20] Synchronize repo HEADs
gitea-doctor[3785590]:  - [I] All 17 repos have their HEADs in the correct state
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [21] Check git-daemon-export-ok files
gitea-doctor[3785590]:  - [I] Checked 17 repositories, 0 need updates.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [22] Check commit-graphs
gitea-doctor[3785590]:  - [I] Checked 17 repositories, 17 without commit-graphs.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [23] Check if users has an valid email address
gitea-doctor[3785590]:  - [I] All users have a valid e-mail.
gitea-doctor[3785590]: OK
gitea-doctor[3785590]: [24] Check if users have a valid username
gitea-doctor[3785590]:  - [I] All users have a valid username.
gitea-doctor[3785590]: OK
systemd[1]: gitea-doctor.service: Succeeded.
systemd[1]: Finished Gitea Doctor: logs about whether there are config/db issues, etc..

There is no convenient workaround that eliminates the ERRORs from the log, but it's acceptable because I have to manually inspect the log anyway, and at least the process doesn't exit non-zero.

Expectations/desired behavior

The reason I think this is a bug, is that certainly for dump, I don't think any valid configuration should cause a standard gitea dump command to fail. It should not be necessary for the standard dump command to be modified just because of config.

IMO the same applies for gitea doctor --all, ideally it would mark as SKIP or even OK any tests that only ERROR because the relevant feature is turned off.

Also important to note, that this did not occur in 1.18.x versions.

Gitea Version

Gitea version 1.19.0 built with GNU Make 4.1, go1.20.2 : bindata, sqlite, sqlite_unlock_notify

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

No response

Screenshots

No response

Git Version

git version 2.39.2

Operating System

Debian GNU/Linux 11 (bullseye)

How are you running Gitea?

Running the latest pre-built x86_64 release from go-gitea/gitea releases (i.e., using one of your downloads).

Running gitea itself in a systemd unit, and running both the backup and doctor commands in systemd units as well.

The gitea unit is primarily:

[Service]
User=gitea
Group=gitea
Type=simple
WorkingDirectory=~
RuntimeDirectory=gitea
LogsDirectory=gitea
StateDirectory=gitea
Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea
ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini

The backup and doctor units are essentially the same basic structure.

Database

SQLite

Originally created by @gavinbeatty on GitHub (Mar 22, 2023). Originally assigned to: @Zettat123 on GitHub. ### Description My /etc/gitea/app.ini contains the following to disable LFS and packages: ``` [server] LFS_START_SERVER = false [packages] ENABLED = false ``` ## gitea dump When running the following dump command (from within a systemd unit running as the same user as the gitea process, everything is set up properly on that end), the dump appears to successfully create a backup archive, but the process logs errors and more importantly, exits non-zero. ``` /usr/bin/env GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea dump -c /etc/gitea/app.ini --type tar.xz --file /var/lib/gitea/backup/gitea/$(date -Iseconds)-gitea-dump ``` Here is the log taken from journalctl output: ``` systemd[1]: Starting Gitea Backup... gitea-backup[3784944]: 2023/03/21 23:58:38 ...es/setting/server.go:328:loadServerFrom() [I] The provided APP_DATA_PATH: data is not absolute - it will be made absolute against the work path: /var/lib/gitea gitea-backup[3784944]: 2023/03/21 23:58:38 ...dules/setting/log.go:331:initLogFrom() [I] Gitea Log Mode: Console(Console:info) gitea-backup[3784944]: 2023/03/21 23:58:38 ...dules/setting/log.go:286:generateNamedLogger() [I] Router Log: Console(console:info) gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/setting/cache.go:75:loadCacheFrom() [I] Cache Service Enabled gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/setting/cache.go:90:loadCacheFrom() [I] Last Commit Cache Service Enabled gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/setting/session.go:74:loadSessionFrom() [I] Session Service Enabled gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:175:initAttachments() [I] Initialising Attachment storage with type: local gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/attachments gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:165:initAvatars() [I] Initialising Avatar storage with type: local gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/avatars gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:191:initRepoAvatars() [I] Initialising Repository Avatar storage with type: local gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/repo-avatars gitea-backup[3784944]: 2023/03/21 23:58:38 ...s/storage/storage.go:197:initRepoArchives() [I] Initialising Repository Archive storage with type: local gitea-backup[3784944]: 2023/03/21 23:58:38 ...les/storage/local.go:45:NewLocalStorage() [I] Creating new Local Storage at /var/lib/gitea/data/repo-archive gitea-backup[3784944]: 2023/03/21 23:58:38 cmd/dump.go:246:runDump() [I] Dumping local repositories... /var/lib/gitea/repos gitea-backup[3784944]: Failed to dump LFS objects: LFS isn't enabled gitea-backup[3784944]: 2023/03/22 00:08:15 cmd/dump.go:162:fatal() [F] Failed to dump LFS objects: LFS isn't enabled systemd[1]: gitea-backup.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: gitea-backup.service: Failed with result 'exit-code'. systemd[1]: Failed to start Gitea Backup. systemd[1]: gitea-backup.service: Consumed 9min 23.556s CPU time. ``` A workaround I am using now is to add `--skip-lfs-data --skip-package-data` to the dump command. ## gitea doctor A similar but not identical issue exists for the following gitea doctor command, where it logs errors but does exit zero: ``` /usr/bin/env GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea doctor -c /etc/gitea/app.ini -w /var/lib/gitea -C /var/lib/gitea/custom --all ``` Log output: ``` systemd[1]: Starting Gitea Doctor: logs about whether there are config/db issues, etc.... gitea-doctor[3785590]: [1] Garbage collect LFS gitea-doctor[3785590]: ERROR gitea-doctor[3785590]: [2] Check paths and basic configuration gitea-doctor[3785590]: - [I] Configuration File Path: "/etc/gitea/app.ini" gitea-doctor[3785590]: - [I] Repository Root Path: "/var/lib/gitea/repos" gitea-doctor[3785590]: - [I] Data Root Path: "/var/lib/gitea/data" gitea-doctor[3785590]: - [I] Custom File Root Path: "/var/lib/gitea/custom" gitea-doctor[3785590]: - [I] Work directory: "/var/lib/gitea" gitea-doctor[3785590]: - [I] Log Root Path: "/var/log/gitea/" gitea-doctor[3785590]: OK gitea-doctor[3785590]: [3] Check if there are orphaned archives in storage gitea-doctor[3785590]: - [I] Found 0 (0 B) repo archive(s) gitea-doctor[3785590]: OK gitea-doctor[3785590]: [4] Check if there are orphaned attachments in storage gitea-doctor[3785590]: - [I] Found 0 (0 B) attachment(s) gitea-doctor[3785590]: OK gitea-doctor[3785590]: [5] Check if there are orphaned avatars in storage gitea-doctor[3785590]: - [I] Found 1 (642 B) avatar(s) gitea-doctor[3785590]: - [I] Found 0 (0 B) repo avatar(s) gitea-doctor[3785590]: OK gitea-doctor[3785590]: [6] Check if there are orphaned lfs files in storage gitea-doctor[3785590]: - [E] Error whilst iterating LFS file storage: LFS isn't enabled gitea-doctor[3785590]: ERROR gitea-doctor[3785590]: [7] Check if there are orphaned package blobs in storage gitea-doctor[3785590]: - [E] Error whilst iterating package blob storage: Packages isn't enabled gitea-doctor[3785590]: ERROR gitea-doctor[3785590]: [8] Check if there are orphaned storage files gitea-doctor[3785590]: - [I] Found 0 (0 B) attachment(s) gitea-doctor[3785590]: - [E] Error whilst iterating LFS file storage: LFS isn't enabled gitea-doctor[3785590]: ERROR gitea-doctor[3785590]: [9] Check Database Version gitea-doctor[3785590]: - [I] Expected database version: 244 gitea-doctor[3785590]: OK gitea-doctor[3785590]: [10] Check consistency of database gitea-doctor[3785590]: OK gitea-doctor[3785590]: [11] Check if user with wrong type exist gitea-doctor[3785590]: OK gitea-doctor[3785590]: [12] Check if OpenSSH authorized_keys file is up-to-date gitea-doctor[3785590]: OK gitea-doctor[3785590]: [13] Check if SCRIPT_TYPE is available gitea-doctor[3785590]: - [I] ScriptType bash is on the current PATH at /usr/bin/bash gitea-doctor[3785590]: OK gitea-doctor[3785590]: [14] Check if hook files are up-to-date and executable gitea-doctor[3785590]: OK gitea-doctor[3785590]: [15] Recalculate Stars number for all user gitea-doctor[3785590]: - [I] No check available for User Stars numbers (skipped) gitea-doctor[3785590]: OK gitea-doctor[3785590]: [16] Check old archives gitea-doctor[3785590]: - [I] 0 old archives in repository need to be deleted gitea-doctor[3785590]: OK gitea-doctor[3785590]: [17] Check that all git repositories have receive.advertisePushOptions set to true gitea-doctor[3785590]: - [I] Checked 17 repositories, 0 need updates. gitea-doctor[3785590]: OK gitea-doctor[3785590]: [18] Check for incorrectly dumped repo_units (See #16961) gitea-doctor[3785590]: - [I] Found no broken repo_units gitea-doctor[3785590]: OK gitea-doctor[3785590]: [19] Recalculate merge bases gitea-doctor[3785590]: - [I] All 0 PRs in 17 repos have a correct mergebase gitea-doctor[3785590]: OK gitea-doctor[3785590]: [20] Synchronize repo HEADs gitea-doctor[3785590]: - [I] All 17 repos have their HEADs in the correct state gitea-doctor[3785590]: OK gitea-doctor[3785590]: [21] Check git-daemon-export-ok files gitea-doctor[3785590]: - [I] Checked 17 repositories, 0 need updates. gitea-doctor[3785590]: OK gitea-doctor[3785590]: [22] Check commit-graphs gitea-doctor[3785590]: - [I] Checked 17 repositories, 17 without commit-graphs. gitea-doctor[3785590]: OK gitea-doctor[3785590]: [23] Check if users has an valid email address gitea-doctor[3785590]: - [I] All users have a valid e-mail. gitea-doctor[3785590]: OK gitea-doctor[3785590]: [24] Check if users have a valid username gitea-doctor[3785590]: - [I] All users have a valid username. gitea-doctor[3785590]: OK systemd[1]: gitea-doctor.service: Succeeded. systemd[1]: Finished Gitea Doctor: logs about whether there are config/db issues, etc.. ``` There is no convenient workaround that eliminates the ERRORs from the log, but it's acceptable because I have to manually inspect the log anyway, and at least the process doesn't exit non-zero. ## Expectations/desired behavior The reason I think this is a bug, is that _certainly_ for dump, I don't think any valid configuration should cause a standard `gitea dump` command to fail. It should not be necessary for the standard dump command to be modified just because of config. IMO the same applies for `gitea doctor --all`, ideally it would mark as SKIP or even OK any tests that only ERROR because the relevant feature is turned off. Also important to note, that this did not occur in 1.18.x versions. ### Gitea Version Gitea version 1.19.0 built with GNU Make 4.1, go1.20.2 : bindata, sqlite, sqlite_unlock_notify ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist _No response_ ### Screenshots _No response_ ### Git Version git version 2.39.2 ### Operating System Debian GNU/Linux 11 (bullseye) ### How are you running Gitea? Running the latest pre-built x86_64 release from go-gitea/gitea releases (i.e., using one of your downloads). Running gitea itself in a systemd unit, and running both the backup and doctor commands in systemd units as well. The gitea unit is primarily: ``` [Service] User=gitea Group=gitea Type=simple WorkingDirectory=~ RuntimeDirectory=gitea LogsDirectory=gitea StateDirectory=gitea Environment=USER=gitea HOME=/var/lib/gitea GITEA_WORK_DIR=/var/lib/gitea ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini ``` The backup and doctor units are essentially the same basic structure. ### Database SQLite
GiteaMirror added the type/bug label 2025-11-02 09:08:22 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label type/bug
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/gitea#10473
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?